9.4-ESV-R2

from unsigned zones. [RT #21131]

CHANGES

@@ -1,5 +1,23 @@
+	--- 9.4-ESV-R2 released ---
 
-	--- 9.4-ESVrc1 released ---
+2876.	[bug]		Named could return SERVFAIL for negative responses
+			from unsigned zones. [RT #21131]
+
+	--- 9.4-ESV-R1 released ---
+
+2852.	[bug]		Handle broken DNSSEC trust chains better. [RT #15619]
+
+	--- 9.4-ESV released ---
+
+2831.	[security]	Do not attempt to validate or cache
+			out-of-bailiwick data returned with a secure
+			answer; it must be re-fetched from its original
+			source and validated in that context. [RT #20819]
+
+2828.	[security]	Cached CNAME or DNAME RR could be returned to clients
+			without DNSSEC validation. [RT #20737]
+
+2827.	[security]	Bogus NXDOMAIN could be cached as if valid. [RT #20712]
 
 2797.	[bug]		Don't decrement the dispatch manager's maxbuffers.
 			[RT #20613]

COPYRIGHT

@@ -1,4 +1,4 @@
-Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2004-2010  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.6 2009/01/05 23:46:19 tbox Exp $
+$Id: COPYRIGHT,v 1.9.18.7 2010/01/07 23:46:07 tbox Exp $
 
 Portions Copyright (C) 1996-2001  Nominum, Inc.
 

README

@@ -27,8 +27,8 @@ BIND 9
 		- Improved Portability Architecture
 
 
-	BIND version 9 development has been underwritten by the following
-	organizations:
+	BIND version 9 development has been under written by the following
+	organisations:
 
 		Sun Microsystems, Inc.
 		Hewlett Packard
@@ -44,13 +44,13 @@ BIND 9
 
 BIND 9.4-ESV (Extended Support Version)
 
-	BIND 9.4-ESV is the final maintenance release for BIND 9.4.
-	BIND 9.4-ESV is a one off maintenance release, fixing bugs in
-	BIND 9.4.3.
+	BIND 9.4-ESV is the Extended Support Version of BIND 9.4
+	and incorporates the final maintenance release fixing bugs
+	in BIND 9.4.3.
 
-	BIND 9.4-ESV will be supported until Feb 2010, at which
-	time you will need to upgrade to the current release of
-	BIND.
+	BIND 9.4-ESV will be supported until December 31, 2010, at
+	which time you will need to upgrade to the current release
+	of BIND.
 
 BIND 9.4.3
 
@@ -77,7 +77,7 @@ BIND 9.4.0
 	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.
+	were provided to control the behaviour.
 
 	New notify type 'master-only'.  Enable notify for master
 	zones only.
@@ -161,12 +161,12 @@ BIND 9.4.0
 	options for dnssec-signzone specify the input and output
 	formats.
 
-	dnssec-signzone can now randomize signature end times
+	dnssec-signzone can now randomise signature end times
 	(dnssec-signzone -j jitter).
 
 	Add support for CH A record.
 
-	Add additional zone data consistancy checks.  named-checkzone
+	Add additional zone data consistency 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.

bin/named/query.c

@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: query.c,v 1.257.18.52 2009/11/25 04:50:24 marka Exp $ */
+/* $Id: query.c,v 1.257.18.53 2009/12/30 08:55:48 jinmei Exp $ */
 
 /*! \file */
 
@@ -3375,8 +3375,6 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 	dns_rdataset_t *noqname;
 	isc_boolean_t resuming;
 	int line = -1;
-	dns_rdataset_t tmprdataset;
-	unsigned int dboptions;
 
 	CTRACE("query_find");
 
@@ -3588,49 +3586,9 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 	/*
 	 * Now look for an answer in the database.
 	 */
-	dboptions = client->query.dboptions;
-	if (sigrdataset == NULL && client->view->enablednssec) {
-		/*
-		 * If the client doesn't want DNSSEC we still want to
-		 * look for any data pending validation to save a remote
-		 * lookup if possible.
-		 */
-		dns_rdataset_init(&tmprdataset);
-		sigrdataset = &tmprdataset;
-		dboptions |= DNS_DBFIND_PENDINGOK;
-	}
- refind:
 	result = dns_db_find(db, client->query.qname, version, type,
-			     dboptions, client->now, &node, fname,
-			     rdataset, sigrdataset);
-	/*
-	 * If we have found pending data try to validate it.
-	 * If the data does not validate as secure and we can't
-	 * use the unvalidated data requery the database with
-	 * pending disabled to prevent infinite looping.
-	 */
-	if (result != ISC_R_SUCCESS || !DNS_TRUST_PENDING(rdataset->trust))
-		goto validation_done;
-	if (validate(client, db, fname, rdataset, sigrdataset))
-		goto validation_done;
-	if (rdataset->trust != dns_trust_pending_answer ||
-	    !PENDINGOK(client->query.dboptions)) {
-		dns_rdataset_disassociate(rdataset);
-		if (sigrdataset != NULL &&
-		    dns_rdataset_isassociated(sigrdataset))
-			dns_rdataset_disassociate(sigrdataset);
-		if (sigrdataset == &tmprdataset)
-			sigrdataset = NULL;
-		dns_db_detachnode(db, &node);
-		dboptions &= ~DNS_DBFIND_PENDINGOK;
-		goto refind;
-	}
- validation_done:
-	if (sigrdataset == &tmprdataset) {
-		if (dns_rdataset_isassociated(sigrdataset))
-			dns_rdataset_disassociate(sigrdataset);
-		sigrdataset = NULL;
-	}
+			     client->query.dboptions, client->now,
+			     &node, fname, rdataset, sigrdataset);
 
  resume:
 	CTRACE("query_find: resume");

bin/named/server.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  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.75 2009/07/11 04:30:49 marka Exp $ */
+/* $Id: server.c,v 1.419.18.77 2010/02/26 23:46:32 tbox Exp $ */
 
 /*! \file */
 
@@ -4563,6 +4563,8 @@ dumpdone(void *arg, isc_result_t result) {
 	}
 	if (dctx->cache != NULL) {
 		dns_adb_dump(dctx->view->view->adb, dctx->fp);
+		dns_resolver_printbadcache(dctx->view->view->resolver,
+					   dctx->fp);
 		dns_db_detach(&dctx->cache);
 	}
 	if (dctx->dumpzones) {

bin/tests/system/dnssec/ns2/example.db.in

@@ -1,7 +1,7 @@
-; Copyright (C) 2004  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 distribute this software for any
+; Permission to use, copy, modify, and/or distribute this software 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: example.db.in,v 1.13.18.2 2004/05/05 01:32:35 marka Exp $
+; $Id: example.db.in,v 1.13.18.4 2009/12/30 23:46:03 tbox Exp $
 
 $TTL 300	; 5 minutes
 @			IN SOA	mname1. . (
@@ -36,6 +36,9 @@ d			A	10.0.0.4
 foo			TXT	"testing"
 foo			A	10.0.1.0
 
+bad-cname		CNAME   a
+bad-dname		DNAME   @
+
 ; Used for testing CNAME queries
 cname1			CNAME	cname1-target
 cname1-target		TXT	"testing cname"

bin/tests/system/dnssec/ns2/sign.sh

@@ -1,9 +1,9 @@
 #!/bin/sh
 #
-# Copyright (C) 2004, 2006  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2006, 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 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: sign.sh,v 1.24.18.2 2006/01/04 00:37:23 marka Exp $
+# $Id: sign.sh,v 1.24.18.4 2009/12/30 23:46:04 tbox Exp $
 
 SYSTEMTESTTOP=../..
 . $SYSTEMTESTTOP/conf.sh
@@ -42,6 +42,53 @@ cat $infile $keyname1.key $keyname2.key >$zonefile
 
 $SIGNER -g -r $RANDFILE -o $zone -k $keyname1 $zonefile $keyname2 > /dev/null
 
+#
+# lower/uppercase the signature bits with the exception of the last characters
+# changing the last 4 characters will lead to a bad base64 encoding.
+#
+$CHECKZONE -D -q -i local $zone $zonefile.signed |
+awk '
+tolower($1) == "bad-cname.example." && $4 == "RRSIG" && $5 == "CNAME" {
+	for (i = 1; i <= NF; i++ ) {
+		if (i <= 12) {
+			printf("%s ", $i);
+			continue;
+		}
+		prefix = substr($i, 1, length($i) - 4);
+		suffix = substr($i, length($i) - 4, 4);
+		if (i > 12 && tolower(prefix) != prefix)
+			printf("%s%s", tolower(prefix), suffix);
+		else if (i > 12 && toupper(prefix) != prefix)
+			printf("%s%s", toupper(prefix), suffix);
+		else
+			printf("%s%s ", prefix, suffix);
+	}
+	printf("\n");
+	next;
+}
+
+tolower($1) == "bad-dname.example." && $4 == "RRSIG" && $5 == "DNAME" {
+	for (i = 1; i <= NF; i++ ) {
+		if (i <= 12) {
+			printf("%s ", $i);
+			continue;
+		}
+		prefix = substr($i, 1, length($i) - 4);
+		suffix = substr($i, length($i) - 4, 4);
+		if (i > 12 && tolower(prefix) != prefix)
+			printf("%s%s", tolower(prefix), suffix);
+		else if (i > 12 && toupper(prefix) != prefix)
+			printf("%s%s", toupper(prefix), suffix);
+		else
+			printf("%s%s ", prefix, suffix);
+	}
+	printf("\n");
+	next;
+}
+
+{ print; }' > $zonefile.signed++ && mv $zonefile.signed++ $zonefile.signed
+
+
 # Sign the privately secure file
 
 privzone=private.secure.example.

bin/tests/system/dnssec/tests.sh

@@ -1,9 +1,9 @@
 #!/bin/sh
 #
-# Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2006, 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 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: tests.sh,v 1.44.18.5 2006/02/26 23:49:49 marka Exp $
+# $Id: tests.sh,v 1.44.18.7 2009/12/30 23:46:03 tbox Exp $
 
 SYSTEMTESTTOP=..
 . $SYSTEMTESTTOP/conf.sh
@@ -177,6 +177,41 @@ n=`expr $n + 1`
 if [ $ret != 0 ]; then echo "I:failed"; fi
 status=`expr $status + $ret`
 
+echo "I:Checking that a bad CNAME signature is caught after a +CD query ($n)"
+ret=0
+#prime
+$DIG $DIGOPTS +cd bad-cname.example. @10.53.0.4 > dig.out.ns4.prime$n || ret=1
+#check: requery with +CD.  pending data should be returned even if it's bogus
+expect="a.example.
+10.0.0.1"
+ans=`$DIG $DIGOPTS +cd +nodnssec +short bad-cname.example. @10.53.0.4` || ret=1
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+#check: requery without +CD.  bogus cached data should be rejected.
+$DIG $DIGOPTS +nodnssec bad-cname.example. @10.53.0.4 > dig.out.ns4.test$n || ret=1
+grep "SERVFAIL" dig.out.ns4.test$n > /dev/null || ret=1
+n=`expr $n + 1`
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
+echo "I:Checking that a bad DNAME signature is caught after a +CD query ($n)"
+ret=0
+#prime
+$DIG $DIGOPTS +cd a.bad-dname.example. @10.53.0.4 > dig.out.ns4.prime$n || ret=1
+#check: requery with +CD.  pending data should be returned even if it's bogus
+expect="example.
+a.example.
+10.0.0.1"
+ans=`$DIG $DIGOPTS +cd +nodnssec +short a.bad-dname.example. @10.53.0.4` || ret=1
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+#check: requery without +CD.  bogus cached data should be rejected.
+$DIG $DIGOPTS +nodnssec a.bad-dname.example. @10.53.0.4 > dig.out.ns4.test$n || ret=1
+grep "SERVFAIL" dig.out.ns4.test$n > /dev/null || ret=1
+n=`expr $n + 1`
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
 # Check the insecure.secure.example domain (insecurity proof)
 
 echo "I:checking 2-server insecurity proof ($n)"

bin/tests/system/pending/clean.sh

@@ -14,9 +14,10 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: clean.sh,v 1.2.14.2 2009/12/03 04:53:09 marka Exp $
+# $Id: clean.sh,v 1.2.14.3 2009/12/30 08:55:48 jinmei Exp $
 
 rm -rf */*.signed
+rm -rf */*.jnl
 rm -rf */K*
 rm -rf */dsset-*
 rm -rf */named.memstats
@@ -24,4 +25,6 @@ rm -rf */named.run
 rm -rf */trusted.conf
 rm -rf ns1/root.db
 rm -rf ns2/example.db
+rm -rf ns2/example.com.db
 rm -rf random.data
+rm -rf nsupdate.out.test

bin/tests/system/pending/ns1/root.db.in

@@ -1,4 +1,4 @@
-; Copyright (C) 2009  Internet Systems Consortium, Inc. ("ISC")
+; Copyright (C) 2009, 2010  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
@@ -12,7 +12,7 @@
 ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 ; PERFORMANCE OF THIS SOFTWARE.
 
-; $Id: root.db.in,v 1.3.8.2 2009/11/25 23:46:52 tbox Exp $
+; $Id: root.db.in,v 1.3.8.5 2010/01/07 23:46:07 tbox Exp $
 
 $TTL 30
 . 			IN SOA	marka.isc.org. a.root.servers.nil. (
@@ -27,5 +27,8 @@ a.root-servers.nil.	A	10.53.0.1
 
 example.		NS	ns2.example.
 ns2.example.		A	10.53.0.2
+example.com.		NS	ns2.example.com.
+ns2.example.com.	A	10.53.0.2
 hostile.		NS	ns3.hostile.
 ns3.hostile.		A	10.53.0.3
+nice.good.		A	10.10.10.10

bin/tests/system/pending/ns1/sign.sh

@@ -1,6 +1,6 @@
 #!/bin/sh 
 #
-# Copyright (C) 2009  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2009, 2010  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 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: sign.sh,v 1.2.14.2 2009/11/25 20:56:08 marka Exp $
+# $Id: sign.sh,v 1.2.14.5 2010/01/07 23:46:07 tbox Exp $
 
 SYSTEMTESTTOP=../..
 . $SYSTEMTESTTOP/conf.sh
@@ -28,12 +28,13 @@ zonefile=root.db
 (cd ../ns2 && sh -e sign.sh )
 
 cp ../ns2/dsset-example. .
+cp ../ns2/dsset-example.com. .
 
 keyname1=`$KEYGEN -r $RANDFILE -a RSASHA1 -b 1024 -n zone $zone`
 keyname2=`$KEYGEN -r $RANDFILE -a RSASHA1 -b 2048 -f KSK -n zone $zone`
 cat $infile $keyname1.key $keyname2.key > $zonefile
 
-$SIGNER -g -r $RANDFILE -o $zone $zonefile > /dev/null
+$SIGNER -g -r $RANDFILE -o $zone $zonefile > /dev/null 2>&1
 
 # Configure the resolving server with a trusted key.
 

bin/tests/system/pending/ns2/example.com.db.in

@@ -0,0 +1,31 @@
+; 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: example.com.db.in,v 1.2 2009/12/30 08:02:22 jinmei Exp $
+
+$TTL 30
+@			IN SOA	mname1. . (
+				2009110300 ; serial
+				20         ; refresh (20 seconds)
+				20         ; retry (20 seconds)
+				1814400    ; expire (3 weeks)
+				3600       ; minimum (1 hour)
+				)
+			NS	ns2
+			MX	10 mail
+ns2			A	10.53.0.2
+mail			A	192.0.2.2
+			AAAA	2001:db8::2
+pending-ok		A	192.0.2.2
+pending-ng		A	192.0.2.102

bin/tests/system/pending/ns2/example.db.in

@@ -1,4 +1,4 @@
-; Copyright (C) 2009  Internet Systems Consortium, Inc. ("ISC")
+; Copyright (C) 2009, 2010  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
@@ -12,9 +12,10 @@
 ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 ; PERFORMANCE OF THIS SOFTWARE.
 
-; $Id: example.db.in,v 1.2 2009/11/17 23:55:18 marka Exp $
+; $Id: example.db.in,v 1.2.14.3 2010/01/07 23:46:07 tbox Exp $
 
 $TTL 30
+$ORIGIN example.
 @			IN SOA	mname1. . (
 				2009110300 ; serial
 				20         ; refresh (20 seconds)
@@ -26,3 +27,5 @@ $TTL 30
 			MX	10 mail
 ns2			A	10.53.0.2
 mail			A	10.0.0.2
+bad			CNAME	nice.good.
+worse                   A       6.6.6.6

bin/tests/system/pending/ns2/forgery.db

@@ -0,0 +1,29 @@
+; Copyright (C) 2010  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: forgery.db,v 1.2.14.2 2010/01/07 23:46:07 tbox Exp $
+
+$TTL 30
+$ORIGIN good.
+@			IN SOA	mname1. . (
+				2009110300 ; serial
+				20         ; refresh (20 seconds)
+				20         ; retry (20 seconds)
+				1814400    ; expire (3 weeks)
+				3600       ; minimum (1 hour)
+				)
+			NS	ns2
+ns2			A	10.53.0.2
+
+nice.good.		CNAME	worse.example.

bin/tests/system/pending/ns2/named.conf

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2009, 2010  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: named.conf,v 1.3.8.2 2009/11/25 23:46:52 tbox Exp $ */
+/* $Id: named.conf,v 1.3.8.5 2010/01/07 23:46:07 tbox Exp $ */
 
 // NS2
 
@@ -45,3 +45,15 @@ zone "example" {
 	type master;
 	file "example.db.signed";
 };
+
+zone "example.com" {
+	type master;
+	file "example.com.db.signed";
+	allow-update { 10.53.0.0/8; };
+};
+
+zone "good" {
+        type master;
+        file "forgery.db";
+        allow-query { any; };
+};

bin/tests/system/pending/ns2/sign.sh

@@ -1,6 +1,6 @@
 #!/bin/sh -e
 #
-# Copyright (C) 2009  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2009, 2010  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,20 +14,22 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: sign.sh,v 1.3.8.3 2009/11/25 23:46:52 tbox Exp $
+# $Id: sign.sh,v 1.3.8.6 2010/01/07 23:46:07 tbox Exp $
 
 SYSTEMTESTTOP=../..
 . $SYSTEMTESTTOP/conf.sh
 
 RANDFILE=../random.data
 
-zone=example.
-infile=example.db.in
-zonefile=example.db
+for domain in example example.com; do
+	zone=${domain}.
+	infile=${domain}.db.in
+	zonefile=${domain}.db
 
-keyname1=`$KEYGEN -r $RANDFILE -a RSASHA1 -b 768 -n zone $zone`
-keyname2=`$KEYGEN -r $RANDFILE -a RSASHA1 -b 1024 -f KSK -n zone $zone`
+	keyname1=`$KEYGEN -r $RANDFILE -a RSASHA1 -b 768 -n zone $zone`
+	keyname2=`$KEYGEN -r $RANDFILE -a RSASHA1 -b 1024 -f KSK -n zone $zone`
 
-cat $infile $keyname1.key $keyname2.key >$zonefile
+	cat $infile $keyname1.key $keyname2.key >$zonefile
 
-$SIGNER -r $RANDFILE -o $zone $zonefile > /dev/null
+	$SIGNER -r $RANDFILE -o $zone $zonefile > /dev/null 2>&1
+done

bin/tests/system/pending/ns4/named.conf

@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */
+/* $Id: named.conf,v 1.2.14.2 2009/12/30 08:55:48 jinmei Exp $ */
 
 controls { /* empty */ };
 
@@ -29,6 +29,7 @@ options {
 	listen-on { 10.53.0.4; };
 	listen-on-v6 { none; };
 	recursion yes;
+	dnssec-validation yes;
 };
 
 zone "." {

bin/tests/system/pending/tests.sh

@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (C) 2009  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2009, 2010  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,22 +14,50 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: tests.sh,v 1.3.8.2 2009/11/25 23:46:52 tbox Exp $
+# $Id: tests.sh,v 1.3.8.5 2010/01/07 23:46:07 tbox Exp $
 
 SYSTEMTESTTOP=..
 . $SYSTEMTESTTOP/conf.sh
 
+# replace_data dname RR old_data new_data
+replace_data()
+{
+	if [ $# -ne 4 ]; then
+		echo I:unexpected input for replace_data
+		return 1
+	fi
+
+	_dname=$1
+	_rr=$2
+	_olddata=$3
+	_newdata=$4
+
+	_ret=0
+	$NSUPDATE -d <<END>> nsupdate.out.test 2>&1 || _ret=1
+server 10.53.0.2 5300
+update delete ${_dname} 30 ${_rr} ${_olddata}
+update add ${_dname} 30 ${_rr} ${_newdata}
+send
+END
+
+	if [ $_ret != 0 ]; then
+		echo I:failed to update the test data
+		return 1
+	fi
+
+	return 0
+}
+
 status=0
 n=0
 
-rm -f dig.out.*
-
-DIGOPTS="+short +tcp +cd -p 5300"
+DIGOPTS="+short +tcp -p 5300"
+DIGOPTS_CD="$DIGOPTS +cd"
 
 echo I:Priming cache.
 ret=0
 expect="10 mail.example."
-ans=`$DIG $DIGOPTS @10.53.0.4 hostile MX` || ret=1
+ans=`$DIG $DIGOPTS_CD @10.53.0.4 hostile MX` || ret=1
 test "$ans" = "$expect" || ret=1
 test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
 status=`expr $status + $ret`
@@ -37,7 +65,116 @@ status=`expr $status + $ret`
 echo I:Checking that bogus additional is not returned with +CD.
 ret=0
 expect="10.0.0.2"
-ans=`$DIG $DIGOPTS @10.53.0.4 mail.example A` || ret=1
+ans=`$DIG $DIGOPTS_CD @10.53.0.4 mail.example A` || ret=1
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+status=`expr $status + $ret`
+
+#
+# Prime cache with pending additional records.  Technically, these should not
+# be promoted to answer, but it's allowed in BIND 9.4.
+#
+echo "I:Priming cache (pending additional A and AAAA)"
+ret=0
+expect="10 mail.example.com."
+ans=`$DIG $DIGOPTS @10.53.0.4 example.com MX` || ret=1
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+status=`expr $status + $ret`
+
+echo "I:Replacing pending A"
+ret=0
+replace_data mail.example.com. A 192.0.2.2 192.0.2.3 || ret=1
+status=`expr $status + $ret`
+
+echo "I:Replacing pending AAAA"
+ret=0
+replace_data mail.example.com. AAAA 2001:db8::2 2001:db8::3 || ret=1
+status=`expr $status + $ret`
+
+echo "I:Checking updated data to be returned (without CD)"
+ret=0
+expect="192.0.2.3"
+ans=`$DIG $DIGOPTS @10.53.0.4 mail.example.com A` || ret=1
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+status=`expr $status + $ret`
+
+echo "I:Checking cached data to be returned (with CD, BIND 9.4 only)" 
+ret=0
+expect="2001:db8::2"
+ans=`$DIG $DIGOPTS_CD @10.53.0.4 mail.example.com AAAA` || ret=1
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+status=`expr $status + $ret`
+
+#
+# Prime cache with a pending answer record.  It can be returned (without
+# validation) with +CD.
+#
+echo "I:Priming cache (pending answer)"
+ret=0
+expect="192.0.2.2"
+ans=`$DIG $DIGOPTS_CD @10.53.0.4 pending-ok.example.com A` || ret=1
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+status=`expr $status + $ret`
+
+echo I:Replacing pending data
+ret=0
+replace_data pending-ok.example.com. A 192.0.2.2 192.0.2.3 || ret=1
+status=`expr $status + $ret`
+
+echo I:Confirming cached pending data to be returned with CD
+ret=0
+expect="192.0.2.2"
+ans=`$DIG $DIGOPTS_CD @10.53.0.4 pending-ok.example.com A` || ret=1
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+status=`expr $status + $ret`
+
+#
+# Prime cache with a pending answer record.  It should not be returned
+# to no-DNSSEC clients.
+#
+echo "I:Priming cache (pending answer)"
+ret=0
+expect="192.0.2.102"
+ans=`$DIG $DIGOPTS_CD @10.53.0.4 pending-ng.example.com A` || ret=1
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+status=`expr $status + $ret`
+
+echo I:Replacing pending data
+ret=0
+replace_data pending-ng.example.com. A 192.0.2.102 192.0.2.103 || ret=1
+status=`expr $status + $ret`
+
+echo I:Confirming updated data returned, not the cached one, without CD
+ret=0
+expect="192.0.2.103"
+ans=`$DIG $DIGOPTS @10.53.0.4 pending-ng.example.com A` || ret=1
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+status=`expr $status + $ret`
+
+#
+# Try to fool the resolver with an out-of-bailiwick CNAME
+#
+echo I:Trying to Prime out-of-bailiwick pending answer with CD
+ret=0
+expect="10.10.10.10"
+ans=`$DIG $DIGOPTS_CD @10.53.0.4 bad.example. A` || ret=1
+ans=`echo $ans | awk '{print $NF}'`
+test "$ans" = "$expect" || ret=1
+test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
+status=`expr $status + $ret`
+
+echo I:Confirming the out-of-bailiwick answer is not cached or reused with CD
+ret=0
+expect="10.10.10.10"
+ans=`$DIG $DIGOPTS_CD @10.53.0.4 nice.good. A` || ret=1
+ans=`echo $ans | awk '{print $NF}'`
 test "$ans" = "$expect" || ret=1
 test $ret = 0 || echo I:failed, got "'""$ans""'", expected "'""$expect""'"
 status=`expr $status + $ret`

doc/arm/Bv9ARM-book.xml

@@ -2,7 +2,7 @@
                "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010  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.111 2009/09/24 21:38:50 jinmei Exp $ -->
+<!-- File: $Id: Bv9ARM-book.xml,v 1.241.18.113 2010/02/26 23:46:35 tbox Exp $ -->
 <book xmlns:xi="http://www.w3.org/2001/XInclude">
   <title>BIND 9 Administrator Reference Manual</title>
 
@@ -30,6 +30,7 @@
       <year>2007</year>
       <year>2008</year>
       <year>2009</year>
+      <year>2010</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -7422,6 +7423,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   <literal>1800</literal> (30 minutes).
                 </para>
 
+		<para>
+		  Lame-ttl also controls the amount of time DNSSEC
+		  validation failures are cached.  There is a minimum
+		  of 30 seconds applied to bad cache entries if the
+		  lame-ttl is set to less than 30 seconds.
+		</para>
+
               </listitem>
             </varlistentry>
 

doc/arm/Bv9ARM.ch01.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.29 2009/07/11 01:31:48 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch01.html,v 1.16.18.30 2010/02/27 01:33:43 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#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>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563412">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564391">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564531">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564712">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
 <dd><dl>
-<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>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564733">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564768">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567173">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567250">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567422">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567553">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="id2563409"></a>Scope of Document</h2></div></div></div>
+<a name="id2563412"></a>Scope of Document</h2></div></div></div>
 <p>
         The Berkeley Internet Name Domain
         (<acronym class="acronym">BIND</acronym>) implements a
@@ -87,7 +87,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564388"></a>Organization of This Document</h2></div></div></div>
+<a name="id2564391"></a>Organization of This Document</h2></div></div></div>
 <p>
         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>
@@ -116,7 +116,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564528"></a>Conventions Used in This Document</h2></div></div></div>
+<a name="id2564531"></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="id2564641"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
+<a name="id2564712"></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="id2564662"></a>DNS Fundamentals</h3></div></div></div>
+<a name="id2564733"></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
@@ -273,7 +273,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564696"></a>Domains and Domain Names</h3></div></div></div>
+<a name="id2564768"></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 +319,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567170"></a>Zones</h3></div></div></div>
+<a name="id2567173"></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 +372,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567246"></a>Authoritative Name Servers</h3></div></div></div>
+<a name="id2567250"></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 +389,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567270"></a>The Primary Master</h4></div></div></div>
+<a name="id2567273"></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 +409,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567300"></a>Slave Servers</h4></div></div></div>
+<a name="id2567303"></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 +425,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567389"></a>Stealth Servers</h4></div></div></div>
+<a name="id2567393"></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 +460,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567419"></a>Caching Name Servers</h3></div></div></div>
+<a name="id2567422"></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 +487,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567523"></a>Forwarding</h4></div></div></div>
+<a name="id2567526"></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 +514,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567549"></a>Name Servers in Multiple Roles</h3></div></div></div>
+<a name="id2567553"></a>Name Servers in Multiple Roles</h3></div></div></div>
 <p>
           The <acronym class="acronym">BIND</acronym> name server can
           simultaneously act as

doc/arm/Bv9ARM.ch02.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.30 2009/07/11 01:31:47 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch02.html,v 1.13.18.31 2010/02/27 01:33:43 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#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>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567587">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567613">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567626">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567721">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567732">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="id2567584"></a>Hardware requirements</h2></div></div></div>
+<a name="id2567587"></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="id2567610"></a>CPU Requirements</h2></div></div></div>
+<a name="id2567613"></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="id2567623"></a>Memory Requirements</h2></div></div></div>
+<a name="id2567626"></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="id2567854"></a>Name Server Intensive Environment Issues</h2></div></div></div>
+<a name="id2567721"></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,7 +124,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567865"></a>Supported Operating Systems</h2></div></div></div>
+<a name="id2567732"></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

doc/arm/Bv9ARM.ch03.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.39 2009/07/11 01:31:48 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch03.html,v 1.35.18.40 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -47,14 +47,14 @@
 <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#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>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567764">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567780">An Authoritative-only Name Server</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568004">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568426">Name Server Operations</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568007">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568429">Name Server Operations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568432">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570041">Signals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568435">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570044">Signals</a></span></dt>
 </dl></dd>
 </dl>
 </div>
@@ -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="id2567897"></a>A Caching-only Name Server</h3></div></div></div>
+<a name="id2567764"></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="id2567913"></a>An Authoritative-only Name Server</h3></div></div></div>
+<a name="id2567780"></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="id2568004"></a>Load Balancing</h2></div></div></div>
+<a name="id2568007"></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="id2568426"></a>Name Server Operations</h2></div></div></div>
+<a name="id2568429"></a>Name Server Operations</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2568432"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
+<a name="id2568435"></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
@@ -739,7 +739,7 @@ controls {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2570041"></a>Signals</h3></div></div></div>
+<a name="id2570044"></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

doc/arm/Bv9ARM.ch04.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.50 2009/07/15 01:32:15 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch04.html,v 1.40.18.51 2010/02/27 01:33:43 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#id2570437">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570455">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570440">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570458">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#id2570958">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571032">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571043">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571085">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571280">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571328">Errors</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571098">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571172">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571182">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571225">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571419">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571467">Errors</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571410">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571459">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571549">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571598">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#id2564086">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564155">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571880">Configuring Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571735">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571804">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571883">Configuring Servers</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572026">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572029">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572156">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572178">Address to Name Lookups Using Nibble Format</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572160">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572181">Address to Name Lookups Using Nibble Format</a></span></dt>
 </dl></dd>
 </dl>
 </div>
@@ -205,7 +205,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2570437"></a>Split DNS</h2></div></div></div>
+<a name="id2570440"></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 +235,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2570455"></a>Example split DNS setup</h3></div></div></div>
+<a name="id2570458"></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 +481,7 @@ nameserver 172.16.72.4
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2570958"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
+<a name="id2571098"></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 +489,7 @@ nameserver 172.16.72.4
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2570976"></a>Automatic Generation</h4></div></div></div>
+<a name="id2571115"></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 +514,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2571014"></a>Manual Generation</h4></div></div></div>
+<a name="id2571154"></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 +529,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571032"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
+<a name="id2571172"></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 +537,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571043"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
+<a name="id2571182"></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
@@ -566,7 +566,7 @@ key host1-host2. {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571085"></a>Instructing the Server to Use the Key</h3></div></div></div>
+<a name="id2571225"></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 +598,7 @@ server 10.1.2.3 {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571280"></a>TSIG Key Based Access Control</h3></div></div></div>
+<a name="id2571419"></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
@@ -626,7 +626,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571328"></a>Errors</h3></div></div></div>
+<a name="id2571467"></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 +652,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="id2571410"></a>TKEY</h2></div></div></div>
+<a name="id2571549"></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,7 +688,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="id2571459"></a>SIG(0)</h2></div></div></div>
+<a name="id2571598"></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 RFC 2931.
@@ -749,7 +749,7 @@ allow-update { key host1-host2. ;};
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564086"></a>Generating Keys</h3></div></div></div>
+<a name="id2571735"></a>Generating Keys</h3></div></div></div>
 <p>
           The <span><strong class="command">dnssec-keygen</strong></span> program is used to
           generate keys.
@@ -800,7 +800,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564155"></a>Signing the Zone</h3></div></div></div>
+<a name="id2571804"></a>Signing the Zone</h3></div></div></div>
 <p>
           The <span><strong class="command">dnssec-signzone</strong></span> program is used
           to
@@ -844,7 +844,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571880"></a>Configuring Servers</h3></div></div></div>
+<a name="id2571883"></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,
@@ -932,7 +932,7 @@ options {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2572026"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
+<a name="id2572029"></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 +971,7 @@ options {
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572156"></a>Address Lookups Using AAAA Records</h3></div></div></div>
+<a name="id2572160"></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 +990,7 @@ host            3600    IN      AAAA    2001:db8::1
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572178"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
+<a name="id2572181"></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

doc/arm/Bv9ARM.ch05.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.41 2009/07/11 01:31:49 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch05.html,v 1.33.18.42 2010/02/27 01:33:44 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#id2572211">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572214">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="id2572211"></a>The Lightweight Resolver Library</h2></div></div></div>
+<a name="id2572214"></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

doc/arm/Bv9ARM.ch06.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.98 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch06.html,v 1.82.18.100 2010/02/27 01:33:44 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -48,52 +48,52 @@
 <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#id2573560">Comment Syntax</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573563">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#id2574164"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574167"><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#id2574422"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574425"><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#id2574851"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574868"><span><strong class="command">include</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574854"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574871"><span><strong class="command">include</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574891"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574915"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575005"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575200"><span><strong class="command">logging</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574894"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574918"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575009"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575203"><span><strong class="command">logging</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577096"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577238"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577302"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577346"><span><strong class="command">masters</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577099"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577241"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577305"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577349"><span><strong class="command">masters</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577361"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577364"><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#id2586451"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586502"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586321"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586372"><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#id2586652"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586590"><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#id2587989"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587995"><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#id2590251">Zone File</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2590189">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#id2592275">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592281">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#id2592890">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593085">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593342"><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#id2592965">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593092">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593349"><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>
 </dl>
@@ -455,7 +455,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="id2573353"></a>Syntax</h4></div></div></div>
+<a name="id2573356"></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,7 +464,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2573381"></a>Definition and Usage</h4></div></div></div>
+<a name="id2573384"></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
@@ -542,7 +542,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2573560"></a>Comment Syntax</h3></div></div></div>
+<a name="id2573563"></a>Comment Syntax</h3></div></div></div>
 <p>
           The <acronym class="acronym">BIND</acronym> 9 comment syntax allows for
           comments to appear
@@ -552,7 +552,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2573575"></a>Syntax</h4></div></div></div>
+<a name="id2573578"></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 +567,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2573605"></a>Definition and Usage</h4></div></div></div>
+<a name="id2573608"></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.
@@ -797,7 +797,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574164"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574167"></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
 };
@@ -880,7 +880,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574422"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574425"></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> }; ]
@@ -1002,12 +1002,12 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574851"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574854"></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="id2574868"></a><span><strong class="command">include</strong></span> Statement Definition and
+<a name="id2574871"></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
@@ -1022,7 +1022,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574891"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574894"></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>;
@@ -1031,7 +1031,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574915"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2574918"></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>)
@@ -1078,7 +1078,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575005"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2575009"></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>
@@ -1102,7 +1102,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575200"></a><span><strong class="command">logging</strong></span> Statement Definition and
+<a name="id2575203"></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
@@ -1136,7 +1136,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2575252"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
+<a name="id2575255"></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.
@@ -1665,7 +1665,7 @@ category notify { null; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2576508"></a>The <span><strong class="command">query-errors</strong></span> Category</h4></div></div></div>
+<a name="id2576512"></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
@@ -1893,7 +1893,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2577096"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577099"></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:
@@ -1908,7 +1908,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2577238"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2577241"></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
@@ -1959,14 +1959,14 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2577302"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577305"></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="id2577346"></a><span><strong class="command">masters</strong></span> Statement Definition and
+<a name="id2577349"></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
@@ -1975,7 +1975,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2577361"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577364"></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:
@@ -3086,7 +3086,7 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2581241"></a>Forwarding</h4></div></div></div>
+<a name="id2581244"></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
@@ -3130,7 +3130,7 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2581368"></a>Dual-stack Servers</h4></div></div></div>
+<a name="id2581371"></a>Dual-stack Servers</h4></div></div></div>
 <p>
             Dual-stack servers are used as servers of last resort to work
             around
@@ -3286,7 +3286,7 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2581867"></a>Interfaces</h4></div></div></div>
+<a name="id2581870"></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
@@ -3719,7 +3719,7 @@ avoid-v6-udp-ports {};
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2582869"></a>UDP Port Lists</h4></div></div></div>
+<a name="id2582872"></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>,
@@ -3761,7 +3761,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="id2582929"></a>Operating System Resource Limits</h4></div></div></div>
+<a name="id2582932"></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
@@ -3922,7 +3922,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="id2583488"></a>Periodic Task Intervals</h4></div></div></div>
+<a name="id2583422"></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>
@@ -4227,14 +4227,22 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 <a name="tuning"></a>Tuning</h4></div></div></div>
 <div class="variablelist"><dl>
 <dt><span class="term"><span><strong class="command">lame-ttl</strong></span></span></dt>
-<dd><p>
+<dd>
+<p>
                   Sets the number of seconds to cache a
                   lame server indication. 0 disables caching. (This is
                   <span class="bold"><strong>NOT</strong></span> recommended.)
                   The default is <code class="literal">600</code> (10 minutes) and the
                   maximum value is
                   <code class="literal">1800</code> (30 minutes).
-                </p></dd>
+                </p>
+<p>
+                  Lame-ttl also controls the amount of time DNSSEC
+                  validation failures are cached.  There is a minimum
+                  of 30 seconds applied to bad cache entries if the
+                  lame-ttl is set to less than 30 seconds.
+                </p>
+</dd>
 <dt><span class="term"><span><strong class="command">max-ncache-ttl</strong></span></span></dt>
 <dd><p>
                   To reduce network traffic and increase performance,
@@ -4993,7 +5001,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="id2586451"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2586321"></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>]
@@ -5002,7 +5010,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="id2586502"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<a name="id2586372"></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
@@ -5045,7 +5053,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="id2586652"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2586590"></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
@@ -5301,10 +5309,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="id2587989"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2587995"></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="id2587996"></a>Zone Types</h4></div></div></div>
+<a name="id2588003"></a>Zone Types</h4></div></div></div>
 <div class="informaltable"><table border="1">
 <colgroup>
 <col>
@@ -5515,7 +5523,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="id2588424"></a>Class</h4></div></div></div>
+<a name="id2588362"></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>),
@@ -5537,7 +5545,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="id2588457"></a>Zone Options</h4></div></div></div>
+<a name="id2588395"></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>
@@ -6038,7 +6046,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2590251"></a>Zone File</h2></div></div></div>
+<a name="id2590189"></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>
@@ -6051,7 +6059,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="id2590269"></a>Resource Records</h4></div></div></div>
+<a name="id2590208"></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
@@ -6741,7 +6749,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="id2591754"></a>Textual expression of RRs</h4></div></div></div>
+<a name="id2591761"></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
@@ -6944,7 +6952,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="id2592275"></a>Discussion of MX Records</h3></div></div></div>
+<a name="id2592281"></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
@@ -7200,7 +7208,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="id2592890"></a>Inverse Mapping in IPv4</h3></div></div></div>
+<a name="id2592965"></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
@@ -7261,7 +7269,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="id2593085"></a>Other Zone File Directives</h3></div></div></div>
+<a name="id2593092"></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
@@ -7276,7 +7284,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="id2593108"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
+<a name="id2593114"></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>
@@ -7304,7 +7312,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="id2593169"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
+<a name="id2593175"></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>
@@ -7340,7 +7348,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="id2593238"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
+<a name="id2593244"></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>
@@ -7359,7 +7367,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="id2593342"></a><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
+<a name="id2593349"></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>

doc/arm/Bv9ARM.ch07.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.84 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch07.html,v 1.75.18.86 2010/02/27 01:33:45 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#id2593952"><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#id2593958"><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#id2594033">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594092">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594039">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594099">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>
@@ -118,7 +118,7 @@ zone "example.com" {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593952"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
+<a name="id2593958"></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>
@@ -144,7 +144,7 @@ zone "example.com" {
         </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2594033"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
+<a name="id2594039"></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
@@ -172,7 +172,7 @@ zone "example.com" {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2594092"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
+<a name="id2594099"></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

doc/arm/Bv9ARM.ch08.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.85 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch08.html,v 1.75.18.87 2010/02/27 01:33:45 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#id2594241">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594246">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#id2594258">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594343">Where Can I Get Help?</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594247">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594252">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#id2594264">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594281">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="id2594241"></a>Common Problems</h2></div></div></div>
+<a name="id2594247"></a>Common Problems</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2594246"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
+<a name="id2594252"></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="id2594258"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
+<a name="id2594264"></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="id2594343"></a>Where Can I Get Help?</h2></div></div></div>
+<a name="id2594281"></a>Where Can I Get Help?</h2></div></div></div>
 <p>
           The Internet Systems Consortium
           (<acronym class="acronym">ISC</acronym>) offers a wide range

doc/arm/Bv9ARM.ch09.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.88 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch09.html,v 1.75.18.90 2010/02/27 01:33:43 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#id2594405">Acknowledgments</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594480">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#id2594645">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594651">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#id2597993">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2598000">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="id2594405"></a>Acknowledgments</h2></div></div></div>
+<a name="id2594480"></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>
@@ -162,7 +162,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2594645"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div>
+<a name="id2594651"></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>
@@ -250,17 +250,17 @@
           </p>
 <div class="bibliography">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2594901"></a>Bibliography</h4></div></div></div>
+<a name="id2594907"></a>Bibliography</h4></div></div></div>
 <div class="bibliodiv">
 <h3 class="title">Standards</h3>
 <div class="biblioentry">
-<a name="id2594912"></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="id2594918"></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="id2594935"></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="id2594941"></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="id2594958"></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="id2594965"></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>
@@ -268,42 +268,42 @@
 <h3 class="title">
 <a name="proposed_standards"></a>Proposed Standards</h3>
 <div class="biblioentry">
-<a name="id2594995"></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="id2595001"></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="id2595021"></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="id2595028"></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="id2595047"></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="id2595053"></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="id2595072"></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="id2595078"></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="id2595095"></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="id2595101"></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="id2595150"></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="id2595157"></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="id2595177"></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="id2595184"></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="id2595204"></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="id2595210"></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="id2595266"></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="id2595272"></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="id2595296"></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="id2595302"></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="id2595325"></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="id2595332"></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="id2595352"></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="id2595358"></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>
@@ -312,19 +312,19 @@
 <h3 class="title">
 <acronym class="acronym">DNS</acronym> Security Proposed Standards</h3>
 <div class="biblioentry">
-<a name="id2595434"></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="id2595441"></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="id2595461"></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="id2595467"></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="id2595497"></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="id2595504"></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="id2595562"></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>
+<a name="id2595569"></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="id2595627"></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="id2595634"></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>
@@ -332,146 +332,146 @@
 <h3 class="title">Other Important RFCs About <acronym class="acronym">DNS</acronym>
                 Implementation</h3>
 <div class="biblioentry">
-<a name="id2595701"></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="id2595707"></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="id2595726"></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="id2595733"></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="id2595795"></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="id2595801"></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="id2595830"></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="id2595836"></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="id2595876"></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="id2595882"></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="id2596002"></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="id2596008"></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="id2596039"></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="id2596045"></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="id2596074"></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="id2596081"></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="id2596129"></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="id2596135"></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="id2596167"></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="id2596173"></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="id2596193"></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="id2596199"></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="id2596218"></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="id2596225"></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="id2596245"></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="id2596251"></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="id2596272"></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="id2596278"></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="id2596311"></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="id2596317"></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="id2596341"></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="id2596347"></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="id2596371"></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="id2596377"></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="id2596413"></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="id2596420"></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="id2596446"></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="id2596453"></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="id2596473"></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="id2596480"></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="id2596497"></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="id2596503"></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="id2596554"></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="id2596561"></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="id2596586"></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="id2596593"></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="id2596612"></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="id2596618"></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="id2596634"></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="id2596641"></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="id2596658"></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="id2596664"></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="id2596704"></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="id2596710"></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="id2596727"></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="id2596733"></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="id2596785"></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="id2596791"></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="id2596876"></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="id2596883"></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="id2596903"></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="id2596909"></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="id2596930"></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="id2596936"></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="id2596966"></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="id2596972"></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="id2597012"></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="id2597018"></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="id2597044"></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="id2597050"></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="id2597090"></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="id2597096"></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="id2597125"></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="id2597131"></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>
@@ -487,47 +487,47 @@
                 </p>
 </div>
 <div class="biblioentry">
-<a name="id2597170"></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="id2597176"></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="id2597192"></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="id2597198"></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="id2597286"></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="id2597292"></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="id2597312"></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="id2597318"></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="id2597335"></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="id2597341"></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="id2597381"></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="id2597387"></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="id2597404"></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="id2597411"></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="id2597431"></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="id2597437"></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="id2597457"></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="id2597463"></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="id2597500"></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="id2597507"></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="id2597558"></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="id2597564"></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="id2597585"></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="id2597591"></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>
@@ -541,39 +541,39 @@
                 </p>
 </div>
 <div class="biblioentry">
-<a name="id2597633"></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="id2597639"></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="id2597672"></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="id2597678"></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="id2597699"></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="id2597705"></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="id2597729"></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="id2597735"></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="id2597754"></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="id2597761"></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="id2597781"></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="id2597787"></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="id2597817"></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="id2597824"></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="id2597853"></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="id2597860"></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="id2597880"></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="id2597886"></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="id2597907"></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="id2597913"></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="id2597952"></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="id2597958"></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>
@@ -594,14 +594,14 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2597993"></a>Other Documents About <acronym class="acronym">BIND</acronym>
+<a name="id2598000"></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="id2598003"></a>Bibliography</h4></div></div></div>
+<a name="id2598009"></a>Bibliography</h4></div></div></div>
 <div class="biblioentry">
-<a name="id2598005"></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="id2598011"></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>

doc/arm/Bv9ARM.ch10.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.11 2009/07/11 01:31:48 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch10.html,v 1.2.2.12 2010/02/27 01:33:42 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

doc/arm/Bv9ARM.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.90 2009/09/25 01:33:43 tbox Exp $ -->
+<!-- $Id: Bv9ARM.html,v 1.85.18.92 2010/02/27 01:33:42 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-2009 Internet Systems Consortium, Inc. ("ISC")</p></div>
+<div><p class="copyright">Copyright © 2004-2010 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#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>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563412">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564391">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564531">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564712">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
 <dd><dl>
-<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>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564733">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564768">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567173">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567250">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567422">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567553">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#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>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567587">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567613">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567626">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567721">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567732">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#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>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567764">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567780">An Authoritative-only Name Server</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568004">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568426">Name Server Operations</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568007">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568429">Name Server Operations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568432">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570041">Signals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568435">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570044">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#id2570437">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570455">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2570440">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570458">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#id2570958">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571032">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571043">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571085">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571280">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571328">Errors</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571098">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571172">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571182">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571225">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571419">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571467">Errors</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571410">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571459">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571549">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571598">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#id2564086">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564155">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571880">Configuring Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571735">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571804">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571883">Configuring Servers</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572026">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572029">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572156">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572178">Address to Name Lookups Using Nibble Format</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572160">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572181">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#id2572211">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572214">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,83 @@
 <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#id2573560">Comment Syntax</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573563">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#id2574164"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574167"><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#id2574422"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574425"><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#id2574851"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574868"><span><strong class="command">include</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574854"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574871"><span><strong class="command">include</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574891"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574915"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575005"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575200"><span><strong class="command">logging</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574894"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574918"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575009"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575203"><span><strong class="command">logging</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577096"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577238"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577302"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577346"><span><strong class="command">masters</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577099"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577241"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577305"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577349"><span><strong class="command">masters</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577361"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577364"><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#id2586451"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586502"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586321"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586372"><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#id2586652"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586590"><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#id2587989"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587995"><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#id2590251">Zone File</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2590189">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#id2592275">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592281">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#id2592890">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593085">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593342"><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#id2592965">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593092">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593349"><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>
 </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#id2593952"><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#id2593958"><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#id2594033">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594092">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594039">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2594099">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#id2594241">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594246">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#id2594258">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594343">Where Can I Get Help?</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594247">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2594252">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#id2594264">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2594281">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#id2594405">Acknowledgments</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594480">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#id2594645">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2594651">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#id2597993">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2598000">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>

doc/arm/man.dig.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.73 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: man.dig.html,v 1.2.2.75 2010/02/27 01:33:43 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="id2563811"></a><h2>DESCRIPTION</h2>
+<a name="id2563885"></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="id2571483"></a><h2>SIMPLE USAGE</h2>
+<a name="id2570739"></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="id2571594"></a><h2>OPTIONS</h2>
+<a name="id2570850"></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="id2625116"></a><h2>QUERY OPTIONS</h2>
+<a name="id2625123"></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
@@ -569,7 +569,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2626171"></a><h2>MULTIPLE QUERIES</h2>
+<a name="id2626178"></a><h2>MULTIPLE QUERIES</h2>
 <p>
       The BIND 9 implementation of <span><strong class="command">dig </strong></span>
       supports
@@ -615,7 +615,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="id2626325"></a><h2>IDN SUPPORT</h2>
+<a name="id2626331"></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.
@@ -629,14 +629,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="id2626354"></a><h2>FILES</h2>
+<a name="id2626428"></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="id2626443"></a><h2>SEE ALSO</h2>
+<a name="id2626450"></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>,
@@ -644,7 +644,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="id2626481"></a><h2>BUGS</h2>
+<a name="id2626487"></a><h2>BUGS</h2>
 <p>
       There are probably too many query options.
     </p>

doc/arm/man.dnssec-keygen.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.74 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: man.dnssec-keygen.html,v 1.2.2.76 2010/02/27 01:33:42 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">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="id2598979"></a><h2>DESCRIPTION</h2>
+<a name="id2598985"></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,7 +58,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598993"></a><h2>OPTIONS</h2>
+<a name="id2598999"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
 <dd>
@@ -166,7 +166,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2599473"></a><h2>GENERATED KEYS</h2>
+<a name="id2599479"></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="id2599580"></a><h2>EXAMPLE</h2>
+<a name="id2599587"></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="id2601548"></a><h2>SEE ALSO</h2>
+<a name="id2601486"></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="id2601579"></a><h2>AUTHOR</h2>
+<a name="id2601517"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

doc/arm/man.dnssec-signzone.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.72 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: man.dnssec-signzone.html,v 1.2.2.74 2010/02/27 01:33:43 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">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>
 <div class="refsect1" lang="en">
-<a name="id2600453"></a><h2>DESCRIPTION</h2>
+<a name="id2600869"></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="id2600472"></a><h2>OPTIONS</h2>
+<a name="id2600888"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a</span></dt>
 <dd><p>
@@ -259,7 +259,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655020"></a><h2>EXAMPLE</h2>
+<a name="id2654958"></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 +288,14 @@ db.example.com.signed
 %</pre>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655093"></a><h2>SEE ALSO</h2>
+<a name="id2655031"></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="id2655117"></a><h2>AUTHOR</h2>
+<a name="id2655056"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

doc/arm/man.host.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.71 2009/09/25 01:33:41 tbox Exp $ -->
+<!-- $Id: man.host.html,v 1.2.2.73 2010/02/27 01:33:43 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">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="id2598285"></a><h2>DESCRIPTION</h2>
+<a name="id2598292"></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.
@@ -202,7 +202,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598800"></a><h2>IDN SUPPORT</h2>
+<a name="id2598806"></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="id2598828"></a><h2>FILES</h2>
+<a name="id2598835"></a><h2>FILES</h2>
 <p><code class="filename">/etc/resolv.conf</code>
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598842"></a><h2>SEE ALSO</h2>
+<a name="id2600419"></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>

doc/arm/man.named-checkconf.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.74 2009/09/25 01:33:44 tbox Exp $ -->
+<!-- $Id: man.named-checkconf.html,v 1.2.2.76 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,14 +50,14 @@
 <div class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [<code class="option">-v</code>] [<code class="option">-j</code>] [<code class="option">-t <em class="replaceable"><code>directory</code></em></code>] {filename} [<code class="option">-z</code>]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2600138"></a><h2>DESCRIPTION</h2>
+<a name="id2601851"></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="id2601040"></a><h2>OPTIONS</h2>
+<a name="id2601865"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-t <em class="replaceable"><code>directory</code></em></span></dt>
 <dd><p>
@@ -88,21 +88,21 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601142"></a><h2>RETURN VALUES</h2>
+<a name="id2601968"></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="id2601156"></a><h2>SEE ALSO</h2>
+<a name="id2601981"></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="id2601186"></a><h2>AUTHOR</h2>
+<a name="id2602011"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

doc/arm/man.named-checkzone.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.78 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.named-checkzone.html,v 1.2.2.80 2010/02/27 01:33:43 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -51,7 +51,7 @@
 <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="id2602458"></a><h2>DESCRIPTION</h2>
+<a name="id2603216"></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,7 +71,7 @@
      </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2602508"></a><h2>OPTIONS</h2>
+<a name="id2603266"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-d</span></dt>
 <dd><p>
@@ -251,14 +251,14 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655786"></a><h2>RETURN VALUES</h2>
+<a name="id2656817"></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="id2655800"></a><h2>SEE ALSO</h2>
+<a name="id2656830"></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 +266,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2655833"></a><h2>AUTHOR</h2>
+<a name="id2656864"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

doc/arm/man.named.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.80 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.named.html,v 1.2.2.82 2010/02/27 01:33:45 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">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>
 <div class="refsect1" lang="en">
-<a name="id2603363"></a><h2>DESCRIPTION</h2>
+<a name="id2603984"></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="id2603394"></a><h2>OPTIONS</h2>
+<a name="id2604014"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-4</span></dt>
 <dd><p>
@@ -234,7 +234,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605824"></a><h2>SIGNALS</h2>
+<a name="id2605898"></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 +255,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605874"></a><h2>CONFIGURATION</h2>
+<a name="id2605948"></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,7 +264,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2606098"></a><h2>FILES</h2>
+<a name="id2605968"></a><h2>FILES</h2>
 <div class="variablelist"><dl>
 <dt><span class="term"><code class="filename">/etc/named.conf</code></span></dt>
 <dd><p>
@@ -277,7 +277,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2606141"></a><h2>SEE ALSO</h2>
+<a name="id2606011"></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 +290,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2606212"></a><h2>AUTHOR</h2>
+<a name="id2606082"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

doc/arm/man.rndc-confgen.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.84 2009/09/25 01:33:43 tbox Exp $ -->
+<!-- $Id: man.rndc-confgen.html,v 1.2.2.86 2010/02/27 01:33:45 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="id2606467"></a><h2>DESCRIPTION</h2>
+<a name="id2606678"></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="id2606601"></a><h2>OPTIONS</h2>
+<a name="id2606812"></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="id2607056"></a><h2>EXAMPLES</h2>
+<a name="id2607267"></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="id2618990"></a><h2>SEE ALSO</h2>
+<a name="id2627803"></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="id2619029"></a><h2>AUTHOR</h2>
+<a name="id2627842"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

doc/arm/man.rndc.conf.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.83 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.rndc.conf.html,v 1.2.2.85 2010/02/27 01:33:45 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="id2603049"></a><h2>DESCRIPTION</h2>
+<a name="id2600666"></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="id2605201"></a><h2>EXAMPLE</h2>
+<a name="id2605480"></a><h2>EXAMPLE</h2>
 <pre class="programlisting">
       options {
         default-server  localhost;
@@ -209,7 +209,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605390"></a><h2>NAME SERVER CONFIGURATION</h2>
+<a name="id2606284"></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="id2605416"></a><h2>SEE ALSO</h2>
+<a name="id2606310"></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="id2605454"></a><h2>AUTHOR</h2>
+<a name="id2606348"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

doc/arm/man.rndc.html

@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and/or 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.82 2009/09/25 01:33:40 tbox Exp $ -->
+<!-- $Id: man.rndc.html,v 1.2.2.84 2010/02/27 01:33:45 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</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="id2604521"></a><h2>DESCRIPTION</h2>
+<a name="id2604801"></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="id2604571"></a><h2>OPTIONS</h2>
+<a name="id2604919"></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="id2604865"></a><h2>LIMITATIONS</h2>
+<a name="id2605144"></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="id2604896"></a><h2>SEE ALSO</h2>
+<a name="id2605175"></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="id2604951"></a><h2>AUTHOR</h2>
+<a name="id2605230"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>

doc/draft/draft-ietf-6man-text-addr-representation-07.txt

@@ -3,13 +3,27 @@
 
 IPv6 Maintenance Working Group                               S. Kawamura
 Internet-Draft                                         NEC BIGLOBE, Ltd.
-Intended status: Informational                              M. Kawashima
-Expires: April 21, 2010                         NEC AccessTechnica, Ltd.
-                                                        October 18, 2009
+Updates: 4291 (if approved)                                 M. Kawashima
+Intended status: Standards Track                NEC AccessTechnica, Ltd.
+Expires: August 29, 2010                               February 25, 2010
 
 
          A Recommendation for IPv6 Address Text Representation
-              draft-ietf-6man-text-addr-representation-01
+              draft-ietf-6man-text-addr-representation-07
+
+Abstract
+
+   As IPv6 deployment increases there will be a dramatic increase in the
+   need to use IPv6 addresses in text.  While the IPv6 address
+   architecture in RFC 4291 section 2.2 describes a flexible model for
+   text representation of an IPv6 address this flexibility has been
+   causing problems for operators, system engineers, and users.  This
+   document defines a canonical textual representation format.  It does
+   not define a format for internal storage, such as within an
+   application or database.  It is expected that the canonical format is
+   followed by humans and systems when representing IPv6 addresses as
+   text, but all implementations must accept and be able to handle any
+   legitimate RFC 4291 format.
 
 Status of this Memo
 
@@ -32,41 +46,71 @@ Status of this Memo
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on April 21, 2010.
+   This Internet-Draft will expire on August 29, 2010.
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 1]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   As IPv6 network grows, there will be more engineers and also non-
-   engineers who will have the need to use an IPv6 address in text.
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 1]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 2]
 
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   While the IPv6 address architecture RFC 4291 section 2.2 depicts a
-   flexible model for text representation of an IPv6 address, this
-   flexibility has been causing problems for operators, system
-   engineers, and users.  This document will describe the problems that
-   a flexible text representation has been causing.  This document also
-   recommends a canonical representation format that best avoids
-   confusion.  It is expected that the canonical format is followed by
-   humans and systems when representing IPv6 addresses as text, but all
-   implementations must accept and be able to handle any legitimate
-   RFC4291 format.
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
 Table of Contents
@@ -86,87 +130,43 @@ Table of Contents
      3.2.  Parsing and Modifying  . . . . . . . . . . . . . . . . . .  7
        3.2.1.  General Summary  . . . . . . . . . . . . . . . . . . .  7
        3.2.2.  Logging  . . . . . . . . . . . . . . . . . . . . . . .  7
-       3.2.3.  Auditing: Case 1 . . . . . . . . . . . . . . . . . . .  8
+       3.2.3.  Auditing: Case 1 . . . . . . . . . . . . . . . . . . .  7
        3.2.4.  Auditing: Case 2 . . . . . . . . . . . . . . . . . . .  8
        3.2.5.  Verification . . . . . . . . . . . . . . . . . . . . .  8
        3.2.6.  Unexpected Modifying . . . . . . . . . . . . . . . . .  8
      3.3.  Operating  . . . . . . . . . . . . . . . . . . . . . . . .  8
        3.3.1.  General Summary  . . . . . . . . . . . . . . . . . . .  8
-       3.3.2.  Customer Calls . . . . . . . . . . . . . . . . . . . .  9
+       3.3.2.  Customer Calls . . . . . . . . . . . . . . . . . . . .  8
        3.3.3.  Abuse  . . . . . . . . . . . . . . . . . . . . . . . .  9
      3.4.  Other Minor Problems . . . . . . . . . . . . . . . . . . .  9
        3.4.1.  Changing Platforms . . . . . . . . . . . . . . . . . .  9
        3.4.2.  Preference in Documentation  . . . . . . . . . . . . .  9
-       3.4.3.  Legibility . . . . . . . . . . . . . . . . . . . . . . 10
-   4.  A Recommendation for IPv6 Text Representation  . . . . . . . . 10
+       3.4.3.  Legibility . . . . . . . . . . . . . . . . . . . . . .  9
+   4.  A Recommendation for IPv6 Text Representation  . . . . . . . .  9
      4.1.  Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10
      4.2.  "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
        4.2.1.  Shorten As Much As Possible  . . . . . . . . . . . . . 10
        4.2.2.  Handling One 16 Bit 0 Field  . . . . . . . . . . . . . 10
        4.2.3.  Choice in Placement of "::"  . . . . . . . . . . . . . 10
-     4.3.  Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 2]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   5.  Text Representation of Special Addresses . . . . . . . . . . . 11
+     4.3.  Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10
+   5.  Text Representation of Special Addresses . . . . . . . . . . . 10
    6.  Notes on Combining IPv6 Addresses with Port Numbers  . . . . . 11
-   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   7.  Prefix Representation  . . . . . . . . . . . . . . . . . . . . 12
    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
    10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
      11.2. Informative References . . . . . . . . . . . . . . . . . . 13
    Appendix A.  For Developers  . . . . . . . . . . . . . . . . . . . 13
-   Appendix B.  Prefix Issues . . . . . . . . . . . . . . . . . . . . 13
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
 
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 3]
+Kawamura & Kawashima     Expires August 29, 2010                [Page 3]
 
-Internet-Draft          IPv6 Text Representation            October 2009
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
 1.  Introduction
@@ -190,11 +190,11 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
       2001:DB8:0:0:1::1
 
-   All the above point to the same IPv6 address.  This flexibility has
-   caused many problems for operators, systems engineers, and customers.
-   The problems will be noted in Section 3.  Also, a canonical
-   representation format to avoid problems will be introduced in
-   Section 4.
+   All of the above examples represent the same IPv6 address.  This
+   flexibility has caused many problems for operators, systems
+   engineers, and customers.  The problems are noted in Section 3.
+   Also, a canonical representation format to avoid problems is
+   introduced in Section 4.
 
 1.1.  Requirements Language
 
@@ -213,16 +213,16 @@ Internet-Draft          IPv6 Text Representation            October 2009
       'It is not necessary to write the leading zeros in an individual
       field.'
 
-   In other words, it is also not necessary to omit leading zeros.  This
+   Conversely it is also not necessary to omit leading zeros.  This
    means that, it is possible to select from such as the following
    example.  The final 16 bit field is different, but all these
-   addresses mean the same.
+   addresses represent the same address.
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 4]
+Kawamura & Kawashima     Expires August 29, 2010                [Page 4]
 
-Internet-Draft          IPv6 Text Representation            October 2009
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
       2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
@@ -245,8 +245,8 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
       2001:db8:aaaa:bbbb:cccc:dddd:0:1
 
-   In case where there are more than one zero fields, there is a choice
-   of how many fields can be shortened.  Examples follow.
+   In case where there is more than one zero fields, there is a choice
+   of how many fields can be shortened.
 
       2001:db8:0:0:0::1
 
@@ -260,8 +260,8 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
       'The "::" can only appear once in an address.'
 
-   This gives a choice on where, in a single address to compress the
-   zero.  Examples are shown below.
+   This gives a choice on where in a single address to compress the
+   zero.
 
       2001:db8::aaaa:0:0:1
 
@@ -269,16 +269,16 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
 2.3.  Uppercase or Lowercase
 
-   [RFC4291] does not mention about preference of uppercase or
-   lowercase.  Various flavors are shown below.
+   [RFC4291] does not mention any preference of uppercase or lowercase.
 
 
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 5]
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 5]
 
-Internet-Draft          IPv6 Text Representation            October 2009
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
       2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
@@ -327,49 +327,45 @@ Internet-Draft          IPv6 Text Representation            October 2009
    record is set to a database, one will likely check the output to see
    if the entry is correct.  If an entity was recorded as 2001:db8::/48,
    but the whois output showed 2001:0db8:0000::/48, most non-engineers
-   would think that their input was wrong, and will likely retry several
+   would think that their input was wrong and will likely retry several
    times or make a frustrated call to the database hostmaster.  If there
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 6]
+Kawamura & Kawashima     Expires August 29, 2010                [Page 6]
 
-Internet-Draft          IPv6 Text Representation            October 2009
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
    was a need to register the same address on different systems, and
    each system showed a different text representation, this would
    confuse people even more.  Although this document focuses on
-   addresses rather than prefixes, this is worth mentioning since
+   addresses rather than prefixes, this is worth mentioning since the
    problems encountered are mostly equal.
 
 3.1.4.  Searching for an Address in a Network Diagram
 
-   Network diagrams and blue-prints contain IP addresses as allocated to
-   system devices.  In times of trouble shooting, there may be a need to
-   search through a diagram to find the point of failure (for example,
-   if a traceroute stopped at 2001:db8::1, one would search the diagram
-   for that address).  This is a technique quite often in use in
-   enterprise networks and managed services.  Again, the different
-   flavors of text representation will result in a time-consuming
-   search, leading to longer MTTR in times of trouble.
+   Network diagrams and blueprints often show what IP addresses are
+   assigned to a system devices.  In times of trouble shooting there may
+   be a need to search through a diagram to find the point of failure
+   (for example, if a traceroute stopped at 2001:db8::1, one would
+   search the diagram for that address).  This is a technique quite
+   often in use in enterprise networks and managed services.  Again, the
+   different flavors of text representation will result in a time-
+   consuming search leading to longer MTTR in times of trouble.
 
 3.2.  Parsing and Modifying
 
 3.2.1.  General Summary
 
-   With all the possible text representation ways, each application must
-   include a module, object, link, etc. to a function that will parse
-   IPv6 addresses in a manner that no matter how it is represented, they
-   will mean the same address.  This is not too much a problem if the
-   output is to be just 'read' or 'managed' by a network engineer.
-   However, many system engineers who integrate complex computer systems
-   to corporate customers will have difficulties finding that their
-   favorite tool will not have this function, or will encounter
-   difficulties such as having to rewrite their macro's or scripts for
-   their customers.  It must be noted that each additional line of a
-   program will result in increased development fees that will be
-   charged to the customers.
+   With all the possible methods of text representation each application
+   must include a module, object, link, etc. to a function that will
+   parse IPv6 addresses in a manner that no matter how it is
+   represented, they will mean the same address.  Many system engineers
+   who integrate complex computer systems for corporate customers will
+   have difficulties finding that their favorite tool will not have this
+   function, or will encounter difficulties such as having to rewrite
+   their macros or scripts for their customers.
 
 3.2.2.  Logging
 
@@ -377,60 +373,57 @@ Internet-Draft          IPv6 Text Representation            October 2009
    address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
    the output would be highly unreadable compared to the IPv4 output.
    The address would have to be parsed and reformed to make it useful
-   for human reading.  This will result in additional code on the
-   applications which will result in extra fees charged to the
-   customers.  Sometimes, logging for critical systems is done by
+   for human reading.  Sometimes logging for critical systems is done by
    mirroring the same traffic to two different systems.  Care must be
-   taken that no matter what the log output is, the logs should be
+   taken so that no matter what the log output is the logs should be
    parsed so they will mean the same.
 
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 7]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
 3.2.3.  Auditing: Case 1
 
    When a router or any other network appliance machine configuration is
    audited, there are many methods to compare the configuration
-   information of a node.  Sometimes, auditing will be done by just
-   comparing the changes made each day.  In this case, if configuration
+   information of a node.  Sometimes auditing will be done by just
+   comparing the changes made each day.  In this case if configuration
    was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 7]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
    0000:0000:0000:0001 just because the new engineer on the block felt
-   it was better, a simple diff will tell you that a different address
-   was configured.  If this was done on a wide scale network, people
-   will be focusing on 'why the extra zeros were put in' instead of
-   doing any real auditing.  Lots of tools are just plain 'diff's that
-   do not take into account address representation rules.
+   it was better, a simple diff will show that a different address was
+   configured.  If this was done on a wide scale network people will be
+   focusing on 'why the extra zeros were put in' instead of doing any
+   real auditing.  Lots of tools are just plain diffs that do not take
+   into account address representation rules.
 
 3.2.4.  Auditing: Case 2
 
    Node configurations will be matched against an information system
-   that manages IP addresses.  If output notation is different, there
-   will need to be a script that is implemented to cover for this.  An
-   SNMP GET of an interface address and text representation in a humanly
-   written text file is highly unlikely to match on first try.
+   that manages IP addresses.  If output notation is different there
+   will need to be a script that is implemented to cover for this.  The
+   result of an SNMP GET operation, converted to text and compared to a
+   textual address written by a human is highly unlikely to match on the
+   first try.
 
 3.2.5.  Verification
 
    Some protocols require certain data fields to be verified.  One
-   example of this is X.509 certificates.  If an IPv6 address was
-   embedded in one of the fields in a certificate, and the verification
-   was done by just a simple textual comparison, the certificate may be
-   maistakenly shown as being invalid due to a difference in text
-   representation methods.
+   example of this is X.509 certificates.  If an IPv6 address field in a
+   certificate was incorrectly verified by converting it to text and
+   making a simple textual comparison to some other address, the
+   certificate may be mistakenly shown as being invalid due to a
+   difference in text representation methods.
 
 3.2.6.  Unexpected Modifying
 
    Sometimes, a system will take an address and modify it as a
    convenience.  For example, a system may take an input of
-   2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some
-   RIR databases).  If the zeros were input for a reason, the outcome
-   may be somewhat unexpected.
+   2001:0db8:0::1 and make the output 2001:db8::1.  If the zeros were
+   input for a reason, the outcome may be somewhat unexpected.
 
 3.3.  Operating
 
@@ -438,34 +431,32 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
    When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
    0:0:1, the system may take the address and show the configuration
-   result as 2001:DB8::1:0:0:1.  A distinguished engineer will know that
-   the right address is set, but an operator, or a customer that is
-   communicating with the operator to solve a problem, is usually not as
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 8]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   distinguished as we would like.  Again, the extra load in checking
-   that the IP address is the same as was intended, will result in fees
-   that will be charged to the customers.
+   result as 2001:DB8::1:0:0:1.  Someone familiar with IPv6 address
+   representation will know that the right address is set, but not
+   everyone may understand this.
 
 3.3.2.  Customer Calls
 
    When a customer calls to inquire about a suspected outage, IPv6
    address representation should be handled with care.  Not all
    customers are engineers nor have the same skill in IPv6 technology.
-   The NOC will have to take extra steps to humanly parse the address to
-   avoid having to explain to the customers that 2001:db8:0:1::1 is the
-   same as 2001:db8::1:0:0:0:1.  This is one thing that will never
-   happen in IPv4 because IPv4 address cannot be abbreviated.
+   The network operations center will have to take extra steps to
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 8]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   humanly parse the address to avoid having to explain to the customers
+   that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1.  This is one
+   thing that will never happen in IPv4 because IPv4 address cannot be
+   abbreviated.
 
 3.3.3.  Abuse
 
-   Network abuse is reported along with the abusing IP address.  This
+   Network abuse reports generally include the abusing IP address.  This
    'reporting' could take any shape or form of the flexible model.  A
    team that handles network abuse must be able to tell the difference
    between a 2001:db8::1:0:1 and 2001:db8:1::0:1.  Mistakes in the
@@ -485,26 +476,14 @@ Internet-Draft          IPv6 Text Representation            October 2009
    the same code may not work as expected due to the difference in IPv6
    address text representation.  Usually, a change in a platform (e.g.
    Unix to Windows, Cisco to Juniper) will result in a major change of
-   code, but flexibility in address representation will increase the
-   work load which will again, result in fees that will be charged to
-   the customers, and also longer down time of systems.
+   code anyway, but flexibility in address representation will increase
+   the work load.
 
 3.4.2.  Preference in Documentation
 
-   A document that is edited by more than one author, may become harder
+   A document that is edited by more than one author may become harder
    to read.
 
-
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 9]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
 3.4.3.  Legibility
 
    Capital case D and 0 can be quite often misread.  Capital B and 8 can
@@ -517,70 +496,89 @@ Internet-Draft          IPv6 Text Representation            October 2009
    addresses is presented in this section.  The recommendation in this
    document is one that, complies fully with [RFC4291], is implemented
    by various operating systems, and is human friendly.  The
-   recommendation in this document SHOULD be followed by humans and
-   systems when generating an address to represent as text, but all
-   implementations MUST accept any legitimate [RFC4291] format.
+   recommendation in this section SHOULD be followed by systems when
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 9]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   generating an address to represent as text, but all implementations
+   MUST accept and be able to handle any legitimate [RFC4291] format.
+   It is advised that humans also follow these recommendations when
+   spelling an address.
 
 4.1.  Handling Leading Zeros in a 16 Bit Field
 
-   Leading zeros should be chopped for human legibility and easier
-   searching.  Also, a single 16 bit 0000 field should be represented as
-   just 0.  Place holder zeros are often cause of misreading.
+   Leading zeros MUST be suppressed.  For example 2001:0db8::0001 is not
+   acceptable and must be represented as 2001:db8::1.  A single 16 bit
+   0000 field MUST be represented as 0.
 
 4.2.  "::" Usage
 
 4.2.1.  Shorten As Much As Possible
 
-   The use of "::" should be used to its maximum capability (i.e. 2001:
-   db8::0:1 is not considered as clean representation).
+   The use of symbol "::" MUST be used to its maximum capability.  For
+   example, 2001:db8::0:1 is not acceptable, because the symbol "::"
+   could have been used to produce a shorter representation 2001:db8::1.
 
 4.2.2.  Handling One 16 Bit 0 Field
 
-   "::" should not be used to shorten just one 16 bit 0 field for it
-   would tend to mislead that there are more than one 16 bit field that
-   is shortened.
+   The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field.
+   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
+   2001:db8::1:1:1:1:1 is not correct.
 
 4.2.3.  Choice in Placement of "::"
 
    When there is an alternative choice in the placement of a "::", the
-   longest run of consecutive 16 bit 0 fields should be shortened (i.e.
-   latter is shortened in 2001:0:0:1:0:0:0:1).  When the length of the
-   consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1),
-   the former is shortened.  This is consistent with many current
-   implementations.  One idea to avoid any confusion, is for the
-   operator to not use 16 bit field 0 in the first 64 bits.  By nature
-   IPv6 addresses are usually assigned or allocated to end-users as
-   longer than 32 bits (typically 48 bits or longer).
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 10]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
+   longest run of consecutive 16 bit 0 fields MUST be shortened (i.e.
+   the sequence with three consecutive zero fields is shortened in 2001:
+   0:0:1:0:0:0:1).  When the length of the consecutive 16 bit 0 fields
+   are equal (i.e. 2001:db8:0:0:1:0:0:1), the first sequence of zero
+   bits MUST be shortened.  For example 2001:db8::1:0:0:1 is correct
+   representation.
 
 4.3.  Lower Case
 
-   Recent implementations tend to represent IPv6 address as lower case.
-   It is better to use lower case to avoid problems such as described in
-   section 3.3.3 and 3.4.3.
+   The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST
+   be represented in lower case.
 
 
 5.  Text Representation of Special Addresses
 
    Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
-   IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in
-   the low-order 32 bits of the address.  These addresses have special
-   representation that may mix hexadecimal and decimal notations.  In
-   cases where there is a choice of whether to express the address as
-   fully hexadecimal or hexadecimal and decimal mixed, and if the
-   address type can be distinguished as having IPv4 addresses embedded
-   in the lower 32 bits solely from the 128bits of the address field
-   itself, mixed notation is the better choice.  However, there may be
-   situations where hexadecimal representation is chosen to meet certain
-   needs.  Addressing those needs is out of the scope of this document.
+   IPv4-translatable addresses [I-D.ietf-behave-address-format] have
+   IPv4 addresses embedded in the low-order 32 bits of the address.
+   These addresses have special representation that may mix hexadecimal
+   and dot decimal notations.  The decimal notation may be used only for
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 10]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   the last 32 bits of the address.  For these addresses, mixed notation
+   is RECOMMENDED if the following condition is met: The address can be
+   distinguished as having IPv4 addresses embedded in the lower 32 bits
+   solely from the address field through the use of a well known prefix.
+   Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
+   writing.  If it is known by some external method that a given prefix
+   is used to embed IPv4, it MAY be represented as mixed notation.
+   Tools that provide options to specify prefixes that are (or are not)
+   to be represented as mixed notation may be useful.
+
+   There is a trade-off here where a recommendation to achieve exact
+   match in a search (no dot decimals whatsoever) and recommendation to
+   help the readability of an addresses (dot decimal whenever possible)
+   does not result in the same solution.  The above recommendation is
+   aimed at fixing the representation as much as possible while leaving
+   the opportunity for future well known prefixes to be represented in a
+   human friendly manner as tools adjust to newly assigned prefixes.
+
    The text representation method noted in Section 4 should be applied
    for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of
    0:0:0:0:0:ffff:192.0.2.1).
@@ -589,8 +587,8 @@ Internet-Draft          IPv6 Text Representation            October 2009
 6.  Notes on Combining IPv6 Addresses with Port Numbers
 
    When IPv6 addresses and port numbers are represented in text combined
-   together, there seems to be many different ways to do so.  Examples
-   are shown below.
+   together, there are many different ways to do so.  Examples are shown
+   below.
 
    o  [2001:db8::1]:80
 
@@ -606,45 +604,36 @@ Internet-Draft          IPv6 Text Representation            October 2009
 
    The situation is not much different in IPv4, but the most ambiguous
    case with IPv6 is the second bullet.  This is due to the "::"usage in
-   IPv6 addresses.  This style is not recommended for its ambiguity.
-   The [] style as expressed in [RFC3986] is recommended.  Other styles
-   are acceptable when cross-platform portability does not become an
+   IPv6 addresses.  This style is NOT RECOMMENDED for its ambiguity.
+   The [] style as expressed in [RFC3986] SHOULD be employed, and is the
+   default unless otherwise specified.  Other styles are acceptable when
+   there is exactly one style for the given context and cross-platform
+   portability does not become an issue.  For URIs containing IPv6
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                [Page 11]
+Kawamura & Kawashima     Expires August 29, 2010               [Page 11]
 
-Internet-Draft          IPv6 Text Representation            October 2009
+Internet-Draft          IPv6 Text Representation           February 2010
 
 
-   issue.
+   address literals, [RFC3986] MUST be followed, as well as the rules in
+   this document.
 
 
-7.  Conclusion
+7.  Prefix Representation
 
-   The recommended format of text representing an IPv6 address is
-   summarized as follows.
-
-      (1) omit leading zeros in a 16 bit field
-
-      (2) when using "::", shorten consecutive zero fields to their
-      maximum extent (leave no zero fields behind).
-
-      (3) "::" used where shortens address the most
-
-      (4) "::" used in the former part in case of a tie breaker
-
-      (5) do not shorten one 16 bit 0 field, but always shorten when
-      there are two or more consecutive 16 bit 0 fields
-
-      (6) use lower case
-
-   Hints for developers are written in the Appendix section.
+   Problems with prefixes are just the same as problems encountered with
+   addresses.  The text representation method of IPv6 prefixes should be
+   no different from that of IPv6 addresses.
 
 
 8.  Security Considerations
 
-   None.
+   This document notes some examples where IPv6 addresses are compared
+   in text format.  The example on Section 3.2.5 is one that may cause a
+   security risk if used for access control.  The common practice of
+   comparing X.509 data is done in binary format.
 
 
 9.  IANA Considerations
@@ -659,18 +648,10 @@ Internet-Draft          IPv6 Text Representation            October 2009
    starting this document.  We also would like to thank Brian Carpenter,
    Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler,
    Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki
-   Vatiainen for their input.  Also a very special thanks to Ron Bonica,
-   Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt
-   Lindqvist for their support in bringing this document to the light of
-   IETF working groups.
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 12]
-
-Internet-Draft          IPv6 Text Representation            October 2009
+   Vatiainen ,Dan Wing, and Doug Barton for their input.  Also a very
+   special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert
+   Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing
+   this document to the light of IETF working groups.
 
 
 11.  References
@@ -680,17 +661,31 @@ Internet-Draft          IPv6 Text Representation            October 2009
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 
+   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
+              (SIIT)", RFC 2765, February 2000.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 12]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
    [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 4291, February 2006.
 
 11.2.  Informative References
 
-   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
-              (SIIT)", RFC 2765, February 2000.
-
-   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-              Resource Identifier (URI): Generic Syntax", STD 66,
-              RFC 3986, January 2005.
+   [I-D.ietf-behave-address-format]
+              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
+              draft-ietf-behave-address-format-04 (work in progress),
+              January 2010.
 
    [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
               Castro, "Application Aspects of IPv6 Transition",
@@ -711,24 +706,6 @@ Appendix A.  For Developers
    be called directly.  See [RFC4038] for details.
 
 
-Appendix B.  Prefix Issues
-
-   Problems with prefixes are just the same as problems encountered with
-   addresses.  Text representation method of IPv6 prefixes should be no
-   different from that of IPv6 addresses.
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 13]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
 Authors' Addresses
 
    Seiichi Kawamura
@@ -741,6 +718,17 @@ Authors' Addresses
    Email: kawamucho@mesh.ad.jp
 
 
+
+
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 13]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
    Masanobu Kawashima
    NEC AccessTechnica, Ltd.
    800, Shimomata
@@ -780,6 +768,18 @@ Authors' Addresses
 
 
 
-Kawamura & Kawashima     Expires April 21, 2010                [Page 14]
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 14]
 
 

doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt

@@ -1,448 +0,0 @@
-
-
-
-DNSEXT                                                         R. Bellis
-Internet-Draft                                                Nominet UK
-Updates: 1035, 1123                                     October 26, 2009
-(if approved)
-Intended status: Standards Track
-Expires: April 29, 2010
-
-
-                         DNS Transport over TCP
-               draft-ietf-dnsext-dns-tcp-requirements-01
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and 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 April 29, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   This document updates the requirements for the support of the TCP
-
-
-
-Bellis                   Expires April 29, 2010                 [Page 1]
-
-Internet-Draft           DNS Transport over TCP             October 2009
-
-
-   protocol for the transport of DNS traffic.
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
-   2.  Terminology used in this document . . . . . . . . . . . . . . . 3
-
-   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
-   4.  Transport Protocol Selection  . . . . . . . . . . . . . . . . . 4
-
-   5.  Dormant Connection Handling . . . . . . . . . . . . . . . . . . 5
-
-   6.  Response re-ordering  . . . . . . . . . . . . . . . . . . . . . 6
-
-   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-
-   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-
-   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 7
-
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis                   Expires April 29, 2010                 [Page 2]
-
-Internet-Draft           DNS Transport over TCP             October 2009
-
-
-1.  Introduction
-
-   Most DNS [RFC1035] transactions take place over the UDP [RFC0792]
-   protocol.  The TCP [RFC0793] protocol is used for zone transfers and
-   is supported by many implementations for the transfer of other
-   packets which exceed the protocol's original 512 byte packet-size
-   limit.
-
-   Section 6.1.3.2 of [RFC1123] states:
-
-      DNS resolvers and recursive servers MUST support UDP, and SHOULD
-      support TCP, for sending (non-zone-transfer) queries.
-
-   However, some implementors have taken the text quoted above to mean
-   that TCP support is truly optional for typical DNS operation.
-
-   This document normatively updates the core DNS protocol
-   specifications such that (except in very limited circumstances)
-   support for the TCP protocol is henceforth REQUIRED.
-
-
-2.  Terminology 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].
-
-
-3.  Discussion
-
-   In the absence of EDNS0 (see below) the normal behaviour of any DNS
-   server needing to send a UDP response that exceeds that 512 byte
-   limit is for the server to truncate the response at the 512 byte
-   limit and set the TC flag in the response header.  When the client
-   receives such a response it takes the TC flag as notice that it
-   should retry over TCP instead.
-
-   RFC 1123 also says:
-
-      ... 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.
-
-   Existing deployments of DNSSEC [RFC4033] have shown that truncation
-   at the 512 byte boundary is now commonplace.  For example an NXDOMAIN
-
-
-
-Bellis                   Expires April 29, 2010                 [Page 3]
-
-Internet-Draft           DNS Transport over TCP             October 2009
-
-
-   (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155]
-   is almost invariably longer than 512 bytes.
-
-   Since the original core specifications for DNS were written, the
-   Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
-   These extensions can be used to indicate that the client is prepared
-   to receive UDP responses longer than 512 bytes.  An EDNS0 compatible
-   server receiving a request from an EDNS0 compatible client may send
-   UDP packets up to that client's announced buffer size without
-   truncation.
-
-   However, transport of UDP packets which exceed the size of the path
-   MTU has been found to be unreliable in some circumstances because of
-   IP packet fragmentation.  Many firewalls routinely block fragmented
-   IP packets, and some implementations lack the software logic
-   necessary to reassemble a fragmented datagram.  Worse still, some
-   devices deliberately refuse to handle DNS packets containing EDNS0
-   options.  Other issues relating to UDP transport and packet size are
-   discussed in [RFC5625].
-
-   The MTU most commonly found in the core of the Internet is around
-   1500 bytes, and even that limit is routinely exceeded by DNSSEC
-   signed responses.
-
-   The future that was anticipated in RFC 1123 has arrived, and the only
-   standardised mechanism which may have resolved the packet size issue
-   has been found inadequate.
-
-
-4.  Transport Protocol Selection
-
-   All DNS implementations MUST support both UDP and TCP transport
-   protocols, except as set out below.
-
-   On a case by case basis, authoritative DNS server operators MAY elect
-   to disable DNS transport over TCP if all of the following conditions
-   are satisfied:
-
-   o  the server is authoritative only
-   o  the server does not support AXFR
-   o  all requests and responses are guaranteed to be <= 512 bytes
-
-   A general purpose stub resolver implementation (e.g. an operating
-   system's DNS resolution library) MUST support TCP since to do
-   otherwise would limit its interoperability with its own clients and
-   with upstream servers.
-
-   A proprietary stub resolver implementation MAY omit support for TCP
-
-
-
-Bellis                   Expires April 29, 2010                 [Page 4]
-
-Internet-Draft           DNS Transport over TCP             October 2009
-
-
-   if it is operating in an environment where truncation can never
-   occur, or if it is prepared to accept a DNS lookup failure should
-   truncation occur.
-
-   A recursive resolver or forwarder MUST support TCP so that it does
-   not prevent long responses from a TCP-capable server from reaching
-   its TCP-capable clients.
-
-   Regarding the choice of when to use UDP or TCP, RFC 1123 says:
-
-      ... a DNS resolver or server that is sending a non-zone-transfer
-      query MUST send a UDP query first.
-
-   That requirement is hereby relaxed.  A resolver SHOULD send a UDP
-   query first, but MAY elect to send a TCP query instead if it has good
-   reason to expect the response would be truncated if it were sent over
-   UDP (with or without EDNS0) or for other operational reasons.
-
-
-5.  Dormant Connection Handling
-
-   Section 4.2.2 of [RFC1035] says:
-
-      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.
-
-   Other more modern protocols (e.g.  HTTP [RFC2616]) have support for
-   persistent TCP connections and operational experience has shown that
-   long timeouts can easily cause resource exhaustion and poor response
-   under heavy load.  Intentionally opening many connections and leaving
-   them dormant can trivially create a "denial of service" attack.
-
-   This document therefore RECOMMENDS that the idle period should be of
-   the order of TBD seconds.
-
-   Servers MAY allow dormant connections to remain open for longer
-   periods, but for the avoidance of doubt persistent DNS connections
-   should generally be considered to be as much for the server's benefit
-   as for the client's.  Therefore if the server needs to unilaterally
-   close a dormant TCP connection it MUST be free to do so whenever
-   required.
-
-   Further recommendations for the tuning of TCP parameters to allow
-   higher throughput or improved resiliency against denial of service
-   attacks are (currently) outside the scope of this document.
-
-
-
-
-
-Bellis                   Expires April 29, 2010                 [Page 5]
-
-Internet-Draft           DNS Transport over TCP             October 2009
-
-
-6.  Response re-ordering
-
-   RFC 1035 is ambiguous on the question of whether TCP queries may be
-   re-ordered - the only relevant text is in Section 4.2.1 which relates
-   to UDP:
-
-      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.
-
-   For the avoidance of future doubt, this requirement is clarified.
-   Client resolvers MUST be able to process responses which arrive in a
-   different order to that in which the requests were sent, regardless
-   of the transport protocol in use.
-
-
-7.  Security Considerations
-
-   Some DNS server operators have expressed concern that wider use of
-   DNS over TCP will expose them to a higher risk of "denial of service"
-   attacks.
-
-   Many large authoritative DNS operators including all but one of the
-   root servers and the vast majority of TLDs already support TCP and
-   attacks against them are infrequent and very rarely successful.
-
-   Operators of recursive servers should ensure that they only accept
-   connections from expected clients, and do not accept them from
-   unknown sources.  In the case of UDP traffic this will protect
-   against reflector attacks [RFC5358] and in the case of TCP traffic it
-   will prevent an unknown client from exhausting the server's limits on
-   the number of concurrent connections.
-
-
-8.  IANA Considerations
-
-   This document requests no IANA actions.
-
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
-              RFC 792, September 1981.
-
-   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
-              RFC 793, September 1981.
-
-
-
-Bellis                   Expires April 29, 2010                 [Page 6]
-
-Internet-Draft           DNS Transport over TCP             October 2009
-
-
-   [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.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-9.2.  Informative References
-
-   [RFC2616]  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.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
-              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
-              October 2008.
-
-   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
-              BCP 152, RFC 5625, August 2009.
-
-
-Appendix A.  Change Log
-
-   NB: to be removed by the RFC Editor before publication.
-
-   draft-ietf-dnsext-dns-tcp-requirements-01
-      Addition of response ordering section
-      Various minor editorial changes from WG reviewers
-
-   draft-ietf-dnsext-dns-tcp-requirements-00
-      Initial draft
-
-
-
-
-
-
-
-Bellis                   Expires April 29, 2010                 [Page 7]
-
-Internet-Draft           DNS Transport over TCP             October 2009
-
-
-Author's Address
-
-   Ray Bellis
-   Nominet UK
-   Edmund Halley Road
-   Oxford  OX4 4DQ
-   United Kingdom
-
-   Phone: +44 1865 332211
-   Email: ray.bellis@nominet.org.uk
-   URI:   http://www.nominet.org.uk/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis                   Expires April 29, 2010                 [Page 8]
-

doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt

@@ -0,0 +1,504 @@
+
+
+
+DNSEXT                                                         R. Bellis
+Internet-Draft                                                Nominet UK
+Updates: 1035, 1123                                       March 22, 2010
+(if approved)
+Intended status: Standards Track
+Expires: September 23, 2010
+
+
+          DNS Transport over TCP - Implementation Requirements
+               draft-ietf-dnsext-dns-tcp-requirements-03
+
+Abstract
+
+   This document updates the requirements for the support of TCP as a
+   transport protocol for DNS implementations.
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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 23, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+
+
+
+Bellis                 Expires September 23, 2010               [Page 1]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+   2.  Terminology used in this document . . . . . . . . . . . . . . . 3
+
+   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+
+   4.  Transport Protocol Selection  . . . . . . . . . . . . . . . . . 4
+
+   5.  Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5
+
+   6.  Response re-ordering  . . . . . . . . . . . . . . . . . . . . . 6
+
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+
+   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
+
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 7
+     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
+
+   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 8
+
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                 Expires September 23, 2010               [Page 2]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
+1.  Introduction
+
+   Most DNS [RFC1035] transactions take place over UDP [RFC0768].  TCP
+   [RFC0793] is always used for zone transfers and is often used for
+   messages whose sizes exceed the DNS protocol's original 512 byte
+   limit.
+
+   Section 6.1.3.2 of [RFC1123] states:
+
+      DNS resolvers and recursive servers MUST support UDP, and SHOULD
+      support TCP, for sending (non-zone-transfer) queries.
+
+   However, some implementors have taken the text quoted above to mean
+   that TCP support is an optional feature of the DNS protocol.
+
+   The majority of DNS server operators already support TCP and the
+   default configuration for most software implementations is to support
+   TCP.  The primary audience for this document is those implementors
+   whose failure to support TCP restricts interoperability and limits
+   deployment of new DNS features.
+
+   This document therefore updates the core DNS protocol specifications
+   such that support for TCP is henceforth a REQUIRED part of a full DNS
+   protocol implementation.
+
+   Whilst this document makes no specific recommendations to operators
+   of DNS servers, it should be noted that failure to support TCP (or
+   blocking of DNS over TCP at the network layer) may result in
+   resolution failure and/or application-level timeouts.
+
+
+2.  Terminology 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].
+
+
+3.  Discussion
+
+   In the absence of EDNS0 (see below) the normal behaviour of any DNS
+   server needing to send a UDP response that would exceed the 512 byte
+   limit is for the server to truncate the response so that it fits
+   within that limit and then set the TC flag in the response header.
+   When the client receives such a response it takes the TC flag as an
+   indication that it should retry over TCP instead.
+
+   RFC 1123 also says:
+
+
+
+Bellis                 Expires September 23, 2010               [Page 3]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
+
+      ... 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.
+
+   Existing deployments of DNSSEC [RFC4033] have shown that truncation
+   at the 512 byte boundary is now commonplace.  For example an NXDOMAIN
+   (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155]
+   is almost invariably larger than 512 bytes.
+
+   Since the original core specifications for DNS were written, the
+   Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
+   These extensions can be used to indicate that the client is prepared
+   to receive UDP responses larger than 512 bytes.  An EDNS0 compatible
+   server receiving a request from an EDNS0 compatible client may send
+   UDP packets up to that client's announced buffer size without
+   truncation.
+
+   However, transport of UDP packets that exceed the size of the path
+   MTU causes IP packet fragmentation, which has been found to be
+   unreliable in some circumstances.  Many firewalls routinely block
+   fragmented IP packets, and some do not implement the algorithms
+   necessary to reassemble fragmented packets.  Worse still, some
+   network devices deliberately refuse to handle DNS packets containing
+   EDNS0 options.  Other issues relating to UDP transport and packet
+   size are discussed in [RFC5625].
+
+   The MTU most commonly found in the core of the Internet is around
+   1500 bytes, and even that limit is routinely exceeded by DNSSEC
+   signed responses.
+
+   The future that was anticipated in RFC 1123 has arrived, and the only
+   standardised UDP-based mechanism which may have resolved the packet
+   size issue has been found inadequate.
+
+
+4.  Transport Protocol Selection
+
+   All general purpose DNS implementations MUST support both UDP and TCP
+   transport.
+
+   o  Authoritative server implementations MUST support TCP so that they
+      do not limit the size of responses.
+
+
+
+
+
+Bellis                 Expires September 23, 2010               [Page 4]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
+   o  Recursive resolver (or forwarder) implementations MUST support TCP
+      so that the do not prevent large responses from a TCP-capable
+      server from reaching its TCP-capable clients.
+   o  Stub resolver implementations (e.g. an operating system's DNS
+      resolution library) MUST support TCP since to do otherwise would
+      limit their interoperability with their own clients and with
+      upstream servers.
+
+   An exception may be made for proprietary stub resolver
+   implementations.  These MAY omit support for TCP if operating in an
+   environment where truncation can never occur, or where DNS lookup
+   failure is acceptable should truncation occur.
+
+   Regarding the choice of when to use UDP or TCP, RFC 1123 says:
+
+      ... a DNS resolver or server that is sending a non-zone-transfer
+      query MUST send a UDP query first.
+
+   That requirement is hereby relaxed.  A resolver SHOULD send a UDP
+   query first, but MAY elect to send a TCP query instead if it has good
+   reason to expect the response would be truncated if it were sent over
+   UDP (with or without EDNS0) or for other operational reasons, in
+   particular if it already has an open TCP connection to the server.
+
+
+5.  Connection Handling
+
+   Section 4.2.2 of [RFC1035] says:
+
+      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.
+
+   Other more modern protocols (e.g.  HTTP [RFC2616]) have support for
+   persistent TCP connections and operational experience has shown that
+   long timeouts can easily cause resource exhaustion and poor response
+   under heavy load.  Intentionally opening many connections and leaving
+   them dormant can trivially create a "denial of service" attack.
+
+   This document therefore RECOMMENDS that the default application-level
+   idle period should be of the order of seconds, but does not specify
+   any particular value.  In practise the idle period may vary
+   dynamically, and servers MAY allow dormant connections to remain open
+   for longer periods as resources permit.
+
+
+
+Bellis                 Expires September 23, 2010               [Page 5]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
+   To mitigate the risk of unintentional server overload, DNS clients
+   MUST take care to minimize the number of concurrent TCP connections
+   made to any individual server.  Similarly servers MAY impose limits
+   on the number of concurrent TCP connections being handled for any
+   particular client.
+
+   Further recommendations for the tuning of TCP stacks to allow higher
+   throughput or improved resiliency against denial of service attacks
+   are outside the scope of this document.
+
+
+6.  Response re-ordering
+
+   RFC 1035 is ambiguous on the question of whether TCP queries may be
+   re-ordered - the only relevant text is in Section 4.2.1 which relates
+   to UDP:
+
+      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.
+
+   For the avoidance of future doubt, this requirement is clarified.
+   Client resolvers MUST be able to process responses which arrive in a
+   different order to that in which the requests were sent, regardless
+   of the transport protocol in use.
+
+
+7.  Security Considerations
+
+   Some DNS server operators have expressed concern that wider use of
+   DNS over TCP will expose them to a higher risk of denial of service
+   (DoS) attacks.
+
+   Although there is a higher risk of such attacks against TCP-enabled
+   servers, techniques for the mitigation of DoS attacks at the network
+   level have improved substantially since DNS was first designed.
+
+   At the time of writing the vast majority of TLD authority servers and
+   all of the root name servers support TCP and the author knows of no
+   evidence to suggest that TCP-based DoS attacks against existing DNS
+   infrastructure are commonplace.
+
+   That notwithstanding, readers are advised to familiarise themselves
+   with [CPNI-TCP].
+
+   Operators of recursive servers should ensure that they only accept
+   connections from expected clients, and do not accept them from
+   unknown sources.  In the case of UDP traffic this will help protect
+
+
+
+Bellis                 Expires September 23, 2010               [Page 6]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
+   against reflector attacks [RFC5358] and in the case of TCP traffic it
+   will prevent an unknown client from exhausting the server's limits on
+   the number of concurrent connections.
+
+
+8.  IANA Considerations
+
+   This document requests no IANA actions.
+
+
+9.  Acknowledgements
+
+   The author would like to thank the document reviewers from the DNSEXT
+   Working Group, and in particular George Barwood, Alex Bligh, Alfred
+   Hoenes, Fernando Gont, Jim Reid, Paul Vixie and Nicholas Weaver.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              August 1980.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+   [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.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+10.2.  Informative References
+
+   [CPNI-TCP]
+              CPNI, "Security Assessment of the Transmission Control
+              Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
+              tn-03-09-security-assessment-TCP.pdf>.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+
+
+
+Bellis                 Expires September 23, 2010               [Page 7]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
+              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+              October 2008.
+
+   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
+              BCP 152, RFC 5625, August 2009.
+
+
+Appendix A.  Change Log
+
+   NB: to be removed by the RFC Editor before publication.
+
+   draft-ietf-dnsext-dns-tcp-requirements-03
+      Editorial nits from WGLC
+      Clarification on "general purpose"
+      Fixed ref to UDP (RFC 768)
+      Included more S.4.2.2 text from RFC 1035 and removed some from
+      this draft relating to connection resets.
+      s/long/large/ for packet sizes
+
+   draft-ietf-dnsext-dns-tcp-requirements-02
+      Change of title - more focus on implementation and not operation
+      Re-write of some of the security section
+      Added recommendation for minimal concurrent connections
+      Minor editorial nits from Alfred Hoenes
+
+   draft-ietf-dnsext-dns-tcp-requirements-01
+      Addition of response ordering section
+      Various minor editorial changes from WG reviewers
+
+   draft-ietf-dnsext-dns-tcp-requirements-00
+      Initial draft
+
+
+
+
+
+
+
+
+
+Bellis                 Expires September 23, 2010               [Page 8]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
+Author's Address
+
+   Ray Bellis
+   Nominet UK
+   Edmund Halley Road
+   Oxford  OX4 4DQ
+   United Kingdom
+
+   Phone: +44 1865 332211
+   Email: ray.bellis@nominet.org.uk
+   URI:   http://www.nominet.org.uk/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                 Expires September 23, 2010               [Page 9]
+

doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt

@@ -5,12 +5,18 @@ Network Working Group                                          S. Weiler
 Internet-Draft                                              SPARTA, Inc.
 Updates: 4033, 4034, 4035, 5155                                D. Blacka
 (if approved)                                             VeriSign, Inc.
-Intended status: Standards Track                       September 5, 2009
-Expires: March 9, 2010
+Intended status: Standards Track                           March 8, 2010
+Expires: September 9, 2010
 
 
          Clarifications and Implementation Notes for DNSSECbis
-                draft-ietf-dnsext-dnssec-bis-updates-09
+                draft-ietf-dnsext-dnssec-bis-updates-10
+
+Abstract
+
+   This document is a collection of technical clarifications to the
+   DNSSECbis document set.  It is meant to serve as a resource to
+   implementors as well as a repository of DNSSECbis errata.
 
 Status of this Memo
 
@@ -33,32 +39,30 @@ Status of this Memo
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on March 9, 2010.
+   This Internet-Draft will expire on September 9, 2010.
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
+   Copyright (c) 2010 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   This document is a collection of technical clarifications to the
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
 
 
 
-Weiler & Blacka           Expires March 9, 2010                 [Page 1]
+Weiler & Blacka         Expires September 9, 2010               [Page 1]
 
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
 
 
-   DNSSECbis document set.  It is meant to serve as a resource to
-   implementors as well as a repository of DNSSECbis errata.
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
 
 
 Table of Contents
@@ -68,56 +72,54 @@ Table of Contents
      1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Important Additions to DNSSSECbis  . . . . . . . . . . . . . .  3
      2.1.  NSEC3 Support  . . . . . . . . . . . . . . . . . . . . . .  3
-     2.2.  SHA-256 Support  . . . . . . . . . . . . . . . . . . . . .  3
+     2.2.  SHA-256 Support  . . . . . . . . . . . . . . . . . . . . .  4
    3.  Security Concerns  . . . . . . . . . . . . . . . . . . . . . .  4
      3.1.  Clarifications on Non-Existence Proofs . . . . . . . . . .  4
-     3.2.  Validating Responses to an ANY Query . . . . . . . . . . .  4
+     3.2.  Validating Responses to an ANY Query . . . . . . . . . . .  5
      3.3.  Check for CNAME  . . . . . . . . . . . . . . . . . . . . .  5
      3.4.  Insecure Delegation Proofs . . . . . . . . . . . . . . . .  5
    4.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
      4.1.  Errors in Canonical Form Type Code List  . . . . . . . . .  5
-     4.2.  Unknown DS Message Digest Algorithms . . . . . . . . . . .  5
+     4.2.  Unknown DS Message Digest Algorithms . . . . . . . . . . .  6
      4.3.  Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
      4.4.  Caution About Local Policy and Multiple RRSIGs . . . . . .  7
      4.5.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
      4.6.  Setting the DO Bit on Replies  . . . . . . . . . . . . . .  7
-     4.7.  Setting the AD bit on Replies  . . . . . . . . . . . . . .  7
-     4.8.  Setting the CD bit on Requests . . . . . . . . . . . . . .  8
-     4.9.  Nested Trust Anchors . . . . . . . . . . . . . . . . . . .  8
-   5.  Minor Corrections and Clarifications . . . . . . . . . . . . .  8
-     5.1.  Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . .  8
-     5.2.  Clarifications on DNSKEY Usage . . . . . . . . . . . . . .  9
-     5.3.  Errors in Examples . . . . . . . . . . . . . . . . . . . .  9
-     5.4.  Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . .  9
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
-   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 11
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
+     4.7.  Setting the AD Bit on Queries  . . . . . . . . . . . . . .  8
+     4.8.  Setting the AD Bit on Replies  . . . . . . . . . . . . . .  8
+     4.9.  Setting the CD bit on Requests . . . . . . . . . . . . . .  8
+     4.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . .  8
+       4.10.1.  Closest Encloser  . . . . . . . . . . . . . . . . . .  9
+       4.10.2.  Accept Any Success  . . . . . . . . . . . . . . . . .  9
+       4.10.3.  Preference Based on Source  . . . . . . . . . . . . . 10
+   5.  Minor Corrections and Clarifications . . . . . . . . . . . . . 10
+     5.1.  Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . . 10
+     5.2.  Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 10
+     5.3.  Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
+     5.4.  Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 13
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
 
 
 
 
-
-
-
-
-
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 2]
+Weiler & Blacka         Expires September 9, 2010               [Page 2]
 
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
 
 
 1.  Introduction and Terminology
 
    This document lists some additions, clarifications and corrections to
    the core DNSSECbis specification, as originally described in
-   [RFC4033], [RFC4034], and [RFC4035].
+   [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
+   (See section Section 2 for more recent additions to that core
+   document set.)
 
    It is intended to serve as a resource for implementors and as a
    repository of items that need to be addressed when advancing the
@@ -139,8 +141,9 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
 
 2.  Important Additions to DNSSSECbis
 
-   This section updates the set of core DNSSEC protocol documents
-   originally specified in Section 10 of [RFC4033].
+   This section lists some documents that should be considered core
+   DNSSEC protocol documents in addition to those originally specified
+   in Section 10 of [RFC4033].
 
 2.1.  NSEC3 Support
 
@@ -154,24 +157,30 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    [RFC5155] should be considered part of the DNS Security Document
    Family as described by [RFC4033], Section 10.
 
+   Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
+   SHA1 and RSASHA1-NSEC3-SHA1) signal that a zone MAY be using NSEC3,
+   rather than NSEC.  The zone MAY indeed be using either and validators
+   supporting these algorithms MUST support both NSEC3 and NSEC
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 3]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
+   responses.
+
 2.2.  SHA-256 Support
 
-   [RFC4509] describes the use of SHA-256 as a digest algorithm for use
-   with Delegation Signer (DS) RRs.  [I-D.ietf-dnsext-dnssec-rsasha256]
-   describes the use of the RSASHA256 algorithm for use in DNSKEY and
-   RRSIG RRs.  Validator implementations are strongly encouraged to
-   include support for this algorithm for DS, DNSKEY, and RRSIG records.
+   [RFC4509] describes the use of SHA-256 as a digest algorithm in
+   Delegation Signer (DS) RRs.  [RFC5702] describes the use of the
+   RSASHA256 algorithm in DNSKEY and RRSIG RRs.  Validator
+   implementations are strongly encouraged to include support for this
+   algorithm for DS, DNSKEY, and RRSIG records.
 
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 3]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
-   Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be
-   considered part of the DNS Security Document Family as described by
-   [RFC4033], Section 10.
+   Both [RFC4509] and [RFC5702] should also be considered part of the
+   DNS Security Document Family as described by [RFC4033], Section 10.
 
 
 3.  Security Concerns
@@ -205,6 +214,17 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
    (original) owner name.
 
+
+
+
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 4]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
 3.2.  Validating Responses to an ANY Query
 
    [RFC4035] does not address how to validate responses when QTYPE=*.
@@ -217,14 +237,6 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    QNAME and QCLASS MUST be validated.  If any of those RRsets fail
    validation, the answer is considered Bogus.  If there are no RRsets
    matching QNAME and QCLASS, that fact MUST be validated according to
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 4]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
    the rules in [RFC4035] Section 5.4 (as clarified in this document).
    To be clear, a validator must not expect to receive all records at
    the QNAME in response to QTYPE=*.
@@ -261,6 +273,14 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    [RFC4034] Section 6.2 item 3 has a list of resource record types for
    which DNS names in the RDATA are downcased for purposes of DNSSEC
    canonical form (for both ordering and signing).  That list
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 5]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
    erroneously contains NSEC and RRSIG.  According to [RFC3755], DNS
    names in the RDATA of NSEC and RRSIG should not be downcased.
 
@@ -273,14 +293,6 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    Section 5.2 of [RFC4035] includes rules for how to handle delegations
    to zones that are signed with entirely unsupported public key
    algorithms, as indicated by the key algorithms shown in those zone's
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 5]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
    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
@@ -317,6 +329,14 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    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
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 6]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
    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 4.2).  In these cases, the
@@ -329,14 +349,6 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    discussed in [RFC4035].
 
    This clarification facilitates the broader use of private algorithms,
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 6]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
    as suggested by [RFC4955].
 
 4.4.  Caution About Local Policy and Multiple RRSIGs
@@ -369,14 +381,27 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
 
 4.6.  Setting the DO Bit on Replies
 
-   [RFC4035] does not provide any instructions to servers as to how to
-   set the DO bit.  Some authoritative server implementations have
-   chosen to copy the DO bit settings from the incoming query to the
-   outgoing response.  Others have chosen to never set the DO bit in
-   responses.  Either behavior is permitted.  To be clear, in replies to
-   queries with the DO-bit set servers may or may not set the DO bit.
+   As stated in [RFC3225], the DO bit of the query MUST be copied in the
+   response.  At least one implementation has done something different,
+   so it may be wise for resolvers to be liberal in what they accept.
 
-4.7.  Setting the AD bit on Replies
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 7]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
+4.7.  Setting the AD Bit on Queries
+
+   The use of the AD bit in the query was previously undefined.  This
+   document defines it as a signal indicating that the requester
+   understands and is interested in the value of the AD bit in the
+   response.  This allows a requestor to indicate that it understands
+   the AD bit without also requesting DNSSEC data via the DO bit.
+
+4.8.  Setting the AD Bit on Replies
 
    Section 3.2.3 of [RFC4035] describes under which conditions a
    validating resolver should set or clear the AD bit in a response.  In
@@ -385,27 +410,29 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    conditions listed in RFC 4035, section 3.2.3, and the request
    contained either a set DO bit or a set AD bit.
 
+4.9.  Setting the CD bit on Requests
 
+   When processing a request with the CD bit set, a resolver SHOULD
+   attempt to return all responsive data, even data that has failed
+   DNSSEC validation.  RFC4035 section 3.2.2 requires a resolver
+   processing a request with the CD bit set to set the CD bit on its
+   upstream queries.
 
+   The guidance in RFC4035 is ambiguous about what to do when a cached
+   response was obtained with the CD bit not set.  In the typical case,
+   no new query is required, nor does the cache need to track the state
+   of the CD bit used to make a given query.  The problem arises when
+   the cached response is a server failure (RCODE 2), which may indicate
+   that the requested data failed DNSSEC validation at an upstream
+   validating resolver.  (RFC2308 permits caching of server failures for
+   up to five minutes.)  In these cases, a new query with the CD bit set
+   is required.
 
-Weiler & Blacka           Expires March 9, 2010                 [Page 7]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+   For efficiency, a validator may wish to set the CD bit on all
+   upstream queries when it has a trust anchor at or above the QNAME
+   (and thus can reasonably expect to be able to validate the response).
 
-
-   Note that the use of the AD bit in the query was previously
-   undefined.  This document defines it as a signal indicating that the
-   requester understands and is interested in the value of the AD bit in
-   the response.  This allows a requestor to indicate that it
-   understands the AD bit without also requesting DNSSEC data via the DO
-   bit.
-
-4.8.  Setting the CD bit on Requests
-
-   When processing a request with the CD bit set, the resolver MUST set
-   the CD bit on its upstream queries.
-
-4.9.  Nested Trust Anchors
+4.10.  Nested Trust Anchors
 
    A DNSSEC validator may be configured such that, for a given response,
    more than one trust anchor could be used to validate the chain of
@@ -414,13 +441,95 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    When the validator is asked to validate a response to
    "www.sub.zone.example.", either trust anchor could apply.
 
-   When presented with this situation, DNSSEC validators SHOULD try all
-   applicable trust anchors until one succeeds.
 
-   There are some scenarios where different behaviors, such as choosing
-   the trust anchor closest to the QNAME of the response, may be
-   desired.  A DNSSEC validator MAY enable such behaviors as
-   configurable overrides.
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 8]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
+   When presented with this situation, DNSSEC validators have a choice
+   of which trust anchor(s) to use.  Which to use is a matter of
+   implementation choice.  It is possible and perhaps advisable to
+   expose the choice of policy as a configuration option.  The rest of
+   this section discusses some possible policies.  As a default, we
+   suggest that validators implement the "Accept Any Success" policy
+   described below in Section 4.10.2 while exposing other policies as
+   configuration options.
+
+4.10.1.  Closest Encloser
+
+   One policy is to choose the trust anchor closest to the QNAME of the
+   response.  In our example, that would be the "zone.example." trust
+   anchor.
+
+   This policy has the advantage of allowing the operator to trivially
+   override a parent zone's trust anchor with one that the operator can
+   validate in a stronger way, perhaps because the resolver operator is
+   affiliated with the zone in question.  This policy also minimizes the
+   number of public key operations needed, which may be of benefit in
+   resource-constrained environments.
+
+   This policy has the disadvantage of possibly giving the user some
+   unexpected and unnecessary validation failures when sub-zone trust
+   anchors are neglected.  As a concrete example, consider a validator
+   that configured a trust anchor for "zone.example." in 2009 and one
+   for "example." in 2011.  In 2012, "zone.example." rolls its KSK and
+   updates its DS records, but the validator operator doesn't update its
+   trust anchor.  With the "closest encloser" policy, the validator gets
+   validation failures.
+
+4.10.2.  Accept Any Success
+
+   Another policy is to try all applicable trust anchors until one gives
+   a validation result of Secure, in which case the final validation
+   result is Secure.  If and only if all applicable trust anchors give a
+   result of Insecure, the final validation result is Insecure.  If one
+   or more trust anchors lead to a Bogus result and there is no Secure
+   result, then the final validation result is Bogus.
+
+   This has the advantage of causing the fewer validation failures,
+   which may deliver a better user experience.  If one trust anchor is
+   out of date (as in our above example), the user may still be able to
+   get a Secure validation result (and see DNS responses).
+
+   This policy has the disadvantage of making the validator subject to
+   compromise of the weakest of these trust anchors while making its
+   relatively painless to keep old trust anchors configured in
+
+
+
+Weiler & Blacka         Expires September 9, 2010               [Page 9]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
+   perpetuity.
+
+4.10.3.  Preference Based on Source
+
+   When the trust anchors have come from different sources (e.g.
+   automated updates ([RFC5011]), one or more DLV registries
+   ([RFC5074]), and manually configured), a validator may wish to choose
+   between them based on the perceived reliability of those sources.
+   The order of precedence might be exposed as a configuration option.
+
+   For example, a validator might choose to prefer trust anchors found
+   in a DLV registry over those manually configured on the theory that
+   the manually configured ones will not be as aggressively maintained.
+
+   Conversely, a validator might choose to prefer manually configured
+   trust anchors over those obtained from a DLV registry on the theory
+   that the manually configured ones have been more carefully
+   authenticated.
+
+   Or the validator might do something more complicated: prefer a sub-
+   set of manually configured trust anchors (based on a configuration
+   option), then trust anchors that have been updated using the RFC5011
+   mechanism, then trust anchors from one DLV registry, then trust
+   anchors from a different DLV registry, then the rest of the manually
+   configured trust anchors.
 
 
 5.  Minor Corrections and Clarifications
@@ -438,23 +547,20 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    does not already have the parent's NS RRset.  Section 4.2 of
    [RFC4035] specifies a mechanism for doing that.
 
-
-
-
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 8]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
 5.2.  Clarifications on DNSKEY Usage
 
    Questions of the form "can I use a different DNSKEY for signing this
    RRset" have occasionally arisen.
 
    The short answer is "yes, absolutely".  You can even use a different
+
+
+
+Weiler & Blacka         Expires September 9, 2010              [Page 10]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
    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
@@ -498,18 +604,19 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
 
    However, the same section contains a regular expression:
 
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 9]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
       Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
 
    The plus sign in the regular expression indicates that there is one
    or more of the preceding element.  This means that there must be at
    least one window block.  If this window block has no types, it
+
+
+
+Weiler & Blacka         Expires September 9, 2010              [Page 11]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
    contradicts with the first statement.  Therefore, the correct text in
    RFC 5155 3.2.1 should be:
 
@@ -538,29 +645,19 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
 
 8.1.  Normative References
 
-   [I-D.ietf-dnsext-dnssec-rsasha256]
-              Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
-              and RRSIG Resource Records for DNSSEC",
-              draft-ietf-dnsext-dnssec-rsasha256-14 (work in progress),
-              June 2009.
-
    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              RFC 1034, STD 13, November 1987.
+              STD 13, RFC 1034, November 1987.
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, BCP 14, March 1997.
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
+              RFC 3225, December 2001.
 
    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "DNS Security Introduction and Requirements",
               RFC 4033, March 2005.
 
-
-
-Weiler & Blacka           Expires March 9, 2010                [Page 10]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "Resource Records for the DNS Security Extensions",
               RFC 4034, March 2005.
@@ -569,6 +666,13 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
               Rose, "Protocol Modifications for the DNS Security
               Extensions", RFC 4035, March 2005.
 
+
+
+Weiler & Blacka         Expires September 9, 2010              [Page 12]
+
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
+
+
    [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
               (DS) Resource Records (RRs)", RFC 4509, May 2006.
 
@@ -576,6 +680,10 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
               Security (DNSSEC) Hashed Authenticated Denial of
               Existence", RFC 5155, March 2008.
 
+   [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
+              and RRSIG Resource Records for DNSSEC", RFC 5702,
+              October 2009.
+
 8.2.  Informative References
 
    [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
@@ -587,6 +695,12 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
    [RFC4955]  Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
               July 2007.
 
+   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+              Trust Anchors", RFC 5011, September 2007.
+
+   [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+              November 2007.
+
 
 Appendix A.  Acknowledgments
 
@@ -607,22 +721,22 @@ Appendix A.  Acknowledgments
    contributed text for Section 4.5.
 
    The bug relating to delegation NSEC RR's in Section 3.1 was found by
-   Roy Badami.  Roy Arends found the related problem with DNAME.
 
 
 
-
-Weiler & Blacka           Expires March 9, 2010                [Page 11]
+Weiler & Blacka         Expires September 9, 2010              [Page 13]
 
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes           March 2010
 
 
+   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 5.3 of this document.
 
-   The editors would like to thank Ed Lewis, Danny Mayer, Olafur
-   Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive
-   comments on the text of this document.
+   The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
+   Olafur Gudmundsson, Suzanne Woolf, and Scott Rose for their
+   substantive comments on the text of this document.
 
 
 Authors' Addresses
@@ -666,7 +780,6 @@ Authors' Addresses
 
 
 
-
-
-Weiler & Blacka           Expires March 9, 2010                [Page 12]
+Weiler & Blacka         Expires September 9, 2010              [Page 14]
 
+

doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt

@@ -1,12 +1,12 @@
 DNS Extensions working group                             V.Dolmatov, Ed.  
 Internet-Draft                                            Cryptocom Ltd.    
-Intended status: Standards Track                      November 30, 2009
-Expires: May 30, 2010                                 
+Intended status: Standards Track                         March 06, 2010
+Expires: September 06, 2010                                 
 
 
  Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
                                for DNSSEC
-                 draft-ietf-dnsext-dnssec-gost-05
+                 draft-ietf-dnsext-dnssec-gost-07
 
 Status of this Memo
 
@@ -29,7 +29,7 @@ Status of this Memo
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on May  10 2010.
+   This Internet-Draft will expire on September 06 2010.
 
 Copyright Notice
 
@@ -37,19 +37,23 @@ Copyright Notice
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
+   Provisions Relating to IETF Documents 
+   (http://trustee.ietf.org/license-info) in effect on the date of 
+   publication of this document. Please review these documents 
+   carefully, as they describe your rights and restrictions with 
+   respect to this document. Code Components extracted from this 
+   document must include Simplified BSD License text as described in
+   Section 4.e of the Trust Legal Provisions and are provided without
+   warranty as described in the Simplified BSD License.
 
 Abstract
 
-   This document describes how to produce signature and hash using 
-   GOST algorithms [DRAFT1, DRAFT2, DRAFT3] for DNSKEY, RRSIG and DS
-   resource records for use in the Domain Name System Security 
-   Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
-
-V.Dolmatov              Expires May  30, 2010               [Page 1]
+   This document describes how to produce signature and hash using
+   GOST (R 34.10-2001, R 34.11-94) algorithms foor DNSKEY, RRSIG and DS
+   resource records for use in the Domain Name System Security
+   Extensions (DNSSEC). 
+   
+V.Dolmatov              Expires September 06, 2010            [Page 1]
 
 Table of Contents
 
@@ -98,7 +102,8 @@ Table of Contents
 
    The term "GOST" is not officially defined, but is usually used to
    refer to the collection of the Russian cryptographic algorithms
-   GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. 
+   GOST R 34.10-2001[DRAFT1], GOST R 34.11-94[DRAFT2], 
+   GOST 28147-89[DRAFT3].
    Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to
    the GOST R 34.10-2001 and GOST R 34.11-94 in this document.
 
@@ -106,7 +111,7 @@ Table of Contents
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].
 
-V.Dolmatov              Expires May  30, 2010                [Page 2]
+V.Dolmatov              Expires September 06, 2010             [Page 2]
 
 2.  DNSKEY Resource Records
 
@@ -121,17 +126,13 @@ V.Dolmatov              Expires May  30, 2010                [Page 2]
    According to [GOST3410], a public key is a point on the elliptic
    curve Q = (x,y).
 
-   The wire representation of a public key MUST contain 66 octets, 
-   where the first octet designates public key parameters, the second
-   octet designates digest parameters next 32 octets contain the 
-   little-endian representation of x and the second 32 octets contain
-   the little-endian representation of y. 
+   The wire representation of a public key MUST contain 64 octets, 
+   where the first 32 octets contain the little-endian representation
+   of x and the second 32 octets contain the little-endian 
+   representation of y. 
    This corresponds to the binary representation of (<y>256||<x>256) 
    from [GOST3410], ch.  5.3.
 
-   The only valid value for both parameters octets is 0.
-   Other parameters octets values are reserved for future use.
-   
    Corresponding public key parameters are those identified by
    id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
    and the digest parameters are those identified by
@@ -145,9 +146,8 @@ V.Dolmatov              Expires May  30, 2010                [Page 2]
    section 2.3.2.
 
    To make this encoding from the wire format of a GOST public key 
-   with the parameters used in this document, prepend the last 64 octets
-   of key data (in other words, substitute first two parameter octets)
-   with the following 37-byte sequence:
+   with the parameters used in this document, prepend the 64 octets
+   of key data with the following 37-byte sequence:
 
    0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 
    0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
@@ -160,19 +160,20 @@ V.Dolmatov              Expires May  30, 2010                [Page 2]
    private key file it must be in one line):
 
    Private-key-format: v1.2
-   Algorithm: {TBA1} (GOST)
-   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgV/S
-             2FXdMtzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E=
+   Algorithm: {TBA1} (ECC-GOST)
+   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c
+             t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA=
+ 
 
-V.Dolmatov              Expires May  30, 2010                [Page 3]
+V.Dolmatov              Expires September 06, 2010             [Page 3]
 
    The following DNSKEY RR stores a DNS zone key for example.net
  
    example.net. 86400 IN DNSKEY 256 3 {TBA1} (
-                                AADMrbi2vAs4hklTmmzGE3WWNtJ8Dll0u0jq
-                                tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6
-                                yB7i836EfzmJo5LP
-                                ) ; key id = 15820
+                                GtTJjmZKUXV+lHLG/6crB6RCR+EJR51Islpa
+                                6FqfT0MUfKhSn1yAo92+LJ0GDssTiAnj0H0I
+                                9Jrfial/yyc5Og==
+                                ) ; key id = 10805
 
 3.  RRSIG Resource Records
 
@@ -214,16 +215,16 @@ V.Dolmatov              Expires May  30, 2010                [Page 3]
    assigned by IANA)
 
    www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
-                                  20000101000000 15820 example.net.
-                                  2MIsZWtEx6pcfQrdl376B8sFg0qxsR8XMHpl
-                                  jHh+V6U7Qte7WwI4C3Z1nFMRVf//C9rO2dGB
-                                  rdp+C7wVoOHBqA== )
+                                  20000101000000 10805 example.net.
+                                  k3m0r5bm6kFQmcRlHshY3jIj7KL6KTUsPIAp
+                                  Vy466khKuWEUoVvSkqI+9tvMQySQgZcEmS0W
+                                  HRFSm0XS5YST5g== )
  
-V.Dolmatov              Expires May  30, 2010                [Page 4]
+V.Dolmatov              Expires September 06, 2010             [Page 4]
 
-  Note: Several GOST signatures calculated for the same message text 
-   differ because of using of a random element is used in signature 
-   generation process.
+  Note: Several ECC-GOST signatures calculated for the same message text 
+  will differ because of using of a random element is used in signature 
+  generation process.
 
 4.  DS Resource Records
 
@@ -241,16 +242,16 @@ V.Dolmatov              Expires May  30, 2010                [Page 4]
    assigned by IANA)
 
    example.net. 86400   DNSKEY  257 3 {TBA1} (
-                                AAADr5vmKVdXo780hSRU1YZYWuMZUbEe9R7C
-                                RRLc7Wj2osDXv2XbCnIpTUx8dVLnLKmDBquu
-                                9tCz5oSsZl0cL0R2
-                                ) ; key id = 21649
-
+                                1aYdqrVz3JJXEURLMdmeI7H1CyTFfPVFBIGA
+                                EabZFP+7NT5KPYXzjDkRbPWleEFbBilDNQNi
+                                q/q4CwA4WR+ovg==
+                                ) ; key id = 6204
+ 
    The DS RR will be
 
-   example.net. 3600 IN DS 21649 {TBA1} {TBA2} (
-             A8146F448569F30B91255BA8E98DE14B18569A524C49593ADCA4103A
-             A44649C6 )
+   example.net. 3600 IN DS 6204 {TBA1} {TBA2} (
+             0E6D6CB303F89DBCF614DA6E21984F7A62D08BDD0A05B3A22CC63D1B
+             553BC61E )
 
 5.  Deployment Considerations
 
@@ -273,25 +274,25 @@ V.Dolmatov              Expires May  30, 2010                [Page 4]
 
 6.1.  Support for GOST signatures
 
-   DNSSEC aware implementations SHOULD be able to support RRSIG and
+   DNSSEC aware implementations MAY be able to support RRSIG and
    DNSKEY resource records created with the GOST algorithms as
    defined in this document.
 
-V.Dolmatov              Expires May  30, 2010                [Page 5]
+V.Dolmatov              Expires September 06, 2010             [Page 5]
 
 6.2.  Support for NSEC3 Denial of Existence
 
-    Any DNSSEC-GOST implementation is required to have either NSEC or
-    NSEC3 support.
+    Any DNSSEC-GOST implementation MUST support both NSEC[RFC4035] and
+    NSEC3 [RFC5155]
 
 6.3  Byte order
 
     Due to the fact that all existing industry implementations of GOST
-    cryptographic libraries are returning GOST blobs in little-endian 
-    format and in order to avoid the necessity for DNSSEC developers 
-    to handle different cryptographic algorithms differently, it was
-    chosen to send these blobs on the wire "as is" without 
-    transformation of endianness.
+    cryptographic libraries are returning GOST blobs without 
+    transformation from little-endian format and in order to avoid the
+    necessity for DNSSEC developers to handle different cryptographic
+    algorithms differently, it was chosen to send these blobs on the
+    wire "as is" without transformation of endianness.
 
 7.  Security considerations
 
@@ -311,12 +312,12 @@ V.Dolmatov              Expires May  30, 2010                [Page 5]
 8.  IANA Considerations
 
    This document updates the IANA registry "DNS Security Algorithm 
-   Numbers [RFC4034]"
+   Numbers" [RFC4034]
    (http://www.iana.org/assignments/dns-sec-alg-numbers).  
    The following entries are added to the registry:
                                      Zone    Trans.
    Value  Algorithm         Mnemonic Signing Sec.  References   Status
-   {TBA1} GOST R 34.10-2001 GOST     Y       *     (this memo)  OPTIONAL
+   {TBA1} GOST R 34.10-2001 ECC-GOST     Y   *    (this memo)  OPTIONAL
 
    This document updates the RFC 4034 Digest Types assignment
    (section A.2)by adding the value and status for the GOST R 34.11-94
@@ -333,7 +334,7 @@ V.Dolmatov              Expires May  30, 2010                [Page 5]
    contributors to these documents are gratefully acknowledged for 
    their hard work.
 
-V.Dolmatov              Expires May  30, 2010                [Page 6]
+V.Dolmatov              Expires September 06, 2010             [Page 6]
 
    The following people provided additional feedback and text: Dmitry 
    Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen 
@@ -389,8 +390,11 @@ V.Dolmatov              Expires May  30, 2010                [Page 6]
              Infrastructure Certificate and CRL Profile", RFC 4491,
              May 2006. 
 
-V.Dolmatov              Expires May  30, 2010               [Page 7]
-
+V.Dolmatov              Expires September 06, 2010            [Page 7]
+ 
+[RFC5155] B. Laurie, G. Sisson, R. Arends and D. Blacka, "DNS 
+             Security (DNSSEC) Hashed Authenticated Denial of 
+             Existence", RFC 5155, February 2008.
 
 10.2.  Informative References
 
@@ -399,21 +403,21 @@ V.Dolmatov              Expires May  30, 2010               [Page 7]
 
    [DRAFT1]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
               "GOST R 34.10-2001 digital signature algorithm"
-              draft-dolmatov-cryptocom-gost34102001-06, 11.10.09
+              draft-dolmatov-cryptocom-gost34102001-08, 12.12.09
               work in progress.
 
 
    [DRAFT2]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
               "GOST R 34.11-94 Hash function algorithm"
-              draft-dolmatov-cryptocom-gost341194-04, 11.10.09
+              draft-dolmatov-cryptocom-gost341194-07, 12.12.09
               work in progress.
 
    [DRAFT3]   Dolmatov V., Kabelev D., Ustinov I., Emelyanova I.,
               "GOST 28147-89 encryption, decryption and MAC algorithms"
-              draft-dolmatov-cryptocom-gost2814789-04, 11.10.09
+              draft-dolmatov-cryptocom-gost2814789-08, 12.12.09
               work in progress.
 
-V.Dolmatov              Expires May  30, 2010                [Page 8]
+V.Dolmatov              Expires September 06, 2010             [Page 8]
 
 
 Authors' Addresses
@@ -440,9 +444,5 @@ Moscow, 117218, Russian Federation
 
 EMail: igus@cryptocom.ru
 
-V.Dolmatov              Expires May  30, 2010                [Page 9]
-
-
-
-
+V.Dolmatov              Expires September 06, 2010             [Page 9]
 

doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt

@@ -5,13 +5,13 @@ DNS Extensions Working Group                                     S. Rose
 Internet-Draft                                                      NIST
 Obsoletes: 2672 (if approved)                              W. Wijngaards
 Updates: 3363,4294                                            NLnet Labs
-(if approved)                                          November 12, 2009
+(if approved)                                             April 20, 2010
 Intended status: Standards Track
-Expires: May 16, 2010
+Expires: October 22, 2010
 
 
                  Update to DNAME Redirection in the DNS
-                 draft-ietf-dnsext-rfc2672bis-dname-18
+                 draft-ietf-dnsext-rfc2672bis-dname-19
 
 Abstract
 
@@ -48,18 +48,18 @@ Status of This Memo
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on May 16, 2010.
+   This Internet-Draft will expire on October 22, 2010.
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                  [Page 1]
+Rose & Wijngaards       Expires October 22, 2010                [Page 1]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
+   Copyright (c) 2010 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
@@ -108,9 +108,9 @@ Copyright Notice
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                  [Page 2]
+Rose & Wijngaards       Expires October 22, 2010                [Page 2]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
 Table of Contents
@@ -120,40 +120,40 @@ Table of Contents
    2.  The DNAME Resource Record  . . . . . . . . . . . . . . . . . .  4
      2.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
      2.2.  The DNAME Substitution . . . . . . . . . . . . . . . . . .  5
-     2.3.  DNAME Owner Name not Redirected Itself . . . . . . . . . .  6
+     2.3.  DNAME Owner Name Matching the QNAME  . . . . . . . . . . .  7
      2.4.  Names Next to and Below a DNAME Record . . . . . . . . . .  7
      2.5.  Compression of the DNAME record. . . . . . . . . . . . . .  7
 
    3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . . .  8
      3.1.  CNAME synthesis  . . . . . . . . . . . . . . . . . . . . .  8
-     3.2.  Server algorithm . . . . . . . . . . . . . . . . . . . . .  8
-     3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 10
-     3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 10
+     3.2.  Server algorithm . . . . . . . . . . . . . . . . . . . . .  9
+     3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 11
+     3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 11
 
    4.  DNAME Discussions in Other Documents . . . . . . . . . . . . . 11
 
-   5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 12
-     5.1.  Canonical hostnames cannot be below DNAME owners . . . . . 12
-     5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 12
+   5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 13
+     5.1.  Canonical hostnames cannot be below DNAME owners . . . . . 13
+     5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13
      5.3.  DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13
        5.3.1.  Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13
-       5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 13
-       5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 13
-       5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 13
-         5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error  . . . . 13
+       5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
+       5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 14
+       5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 14
+         5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error  . . . . 14
          5.3.4.2.  Valid Name Error Response Involving DNAME in
-                   Bitmap . . . . . . . . . . . . . . . . . . . . . . 14
-         5.3.4.3.  Response With Synthesized CNAME  . . . . . . . . . 14
+                   Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
+         5.3.4.3.  Response With Synthesized CNAME  . . . . . . . . . 15
 
    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
 
    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
 
-   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
 
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
 
 
 
@@ -164,9 +164,9 @@ Table of Contents
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                  [Page 3]
+Rose & Wijngaards       Expires October 22, 2010                [Page 3]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
 1.  Introduction
@@ -180,7 +180,7 @@ Internet-Draft              DNAME Redirection              November 2009
    from the queried domain name.  The difference between the two
    resource records is that the CNAME RR directs the lookup of data at
    its owner to another single name, a DNAME RR directs lookups for data
-   at descendents of its owner's name to corresponding names under a
+   at descendants of its owner's name to corresponding names under a
    different (single) node of the tree.
 
    Take for example, looking through a zone (see RFC 1034 [RFC1034],
@@ -220,9 +220,9 @@ Internet-Draft              DNAME Redirection              November 2009
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                  [Page 4]
+Rose & Wijngaards       Expires October 22, 2010                [Page 4]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
    Its RDATA is comprised of a single field, <target>, which contains a
@@ -234,9 +234,10 @@ Internet-Draft              DNAME Redirection              November 2009
 
    The effect of the DNAME RR is the substitution of the record's
    <target> for its owner name, as a suffix of a domain name.  This
-   substitution has to be applied for every DNAME RR found in the
-   resolution process, which allows fairly lengthy valid chains of DNAME
-   RRs.
+   substitution is to be applied for all names below the owner name of
+   the DNAME RR.  This substitution has to be applied for every DNAME RR
+   found in the resolution process, which allows fairly lengthy valid
+   chains of DNAME RRs.
 
    Details of the substitution process, methods to avoid conflicting
    resource records, and rules for specific corner cases are given in
@@ -275,10 +276,9 @@ Internet-Draft              DNAME Redirection              November 2009
 
 
 
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 5]
+Rose & Wijngaards       Expires October 22, 2010                [Page 5]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
    In the table below, the QNAME refers to the query name.  The owner is
@@ -293,7 +293,7 @@ Internet-Draft              DNAME Redirection              November 2009
     QNAME            owner  DNAME   target         result
     ---------------- -------------- -------------- -----------------
     com.             example.com.   example.net.   <no match>
-    example.com.     example.com.   example.net.   <no match>
+    example.com.     example.com.   example.net.   [0]
     a.example.com.   example.com.   example.net.   a.example.net.
     a.b.example.com. example.com.   example.net.   a.b.example.net.
     ab.example.com.  b.example.com. example.net.   <no match>
@@ -305,6 +305,9 @@ Internet-Draft              DNAME Redirection              November 2009
     shortloop.x.x.   x.             .              shortloop.x.
     shortloop.x.     x.             .              shortloop.
 
+   [0] The result depends on the QTYPE.  If the QTYPE = DNAME, then
+       the result is "example.com." else "<no match>"
+
                    Table 1. DNAME Substitution Examples.
 
    It is possible for DNAMEs to form loops, just as CNAMEs can form
@@ -323,23 +326,32 @@ Internet-Draft              DNAME Redirection              November 2009
    DNAME record and its signature (if the zone is signed) are included
    in the answer as proof for the YXDOMAIN (value 6) RCODE.
 
-2.3.  DNAME Owner Name not Redirected Itself
+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 6]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
+2.3.  DNAME Owner Name Matching the QNAME
 
    Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
    owner name; the owner name of a DNAME is not redirected itself.  The
    domain name that owns a DNAME record is allowed to have other
    resource record types at that domain name, except DNAMEs, CNAMEs or
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 6]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
    other types that have restrictions on what they can co-exist with.
+   When there is a match of the QTYPE to a type (or types) also owned by
+   the owner name the response is sourced from the owner name.  E.g., a
+   QTYPE of ANY would return the (available) types at the owner name,
+   not the target name.
+
    DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
-   the owner name is the zone apex.
+   the owner name is the zone apex as this would constitute data below a
+   zone cut.
 
    If a DNAME record is present at the zone apex, there is still a need
    to have the customary SOA and NS resource records there as well.
@@ -373,6 +385,14 @@ Internet-Draft              DNAME Redirection              November 2009
 
    The DNAME owner name can be compressed like any other owner name.
    The DNAME RDATA target name MUST NOT be sent out in compressed form,
+
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 7]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
    so that a DNAME RR can be treated as an unknown type [RFC3597].
 
    Although the previous DNAME specification [RFC2672] (that is
@@ -386,13 +406,6 @@ Internet-Draft              DNAME Redirection              November 2009
    compression.  This document revises RFC 2672, in that there is no
    EDNS version signaling for DNAME.
 
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 7]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
 3.  Processing
 
    The DNAME RR causes type NS additional section processing.  This
@@ -403,22 +416,44 @@ Internet-Draft              DNAME Redirection              November 2009
 
    When preparing a response, a server performing a DNAME substitution
    will in all cases include the relevant DNAME RR in the answer
-   section.  A CNAME RR with TTL equal to the corresponding DNAME RR is
-   synthesized and included in the answer section.  The owner name of
-   the CNAME is the QNAME of the query.  The DNSSEC specification
-   [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does
-   not have to be signed.  The DNAME has an RRSIG and a validating
-   resolver can check the CNAME against the DNAME record and validate
-   the signature over the DNAME RR.
+   section.  Relevant includes the following cases:
 
-   Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
-   equal to the TTL of the corresponding DNAME record.  A TTL of zero
-   means that the CNAME can be discarded immediately after processing
-   the answer.
+   1.  The DNAME is being employed as a substitution instruction.
+
+   2.  The DNAME itself matches the QTYPE and the owner name matches
+       QNAME.
+
+   When the owner name name matches the QNAME and the QTYPE matches
+   another type owned there, the DNAME is not included in the answer.
+
+   A CNAME RR with TTL equal to the corresponding DNAME RR is
+   synthesized and included in the answer section when the DNAME is
+   employed as a substitution instruction.  The owner name of the CNAME
+   is the QNAME of the query.  The DNSSEC specification [RFC4033],
+   [RFC4034], [RFC4035] says that the synthesized CNAME does not have to
+   be signed.  The DNAME has an RRSIG and a validating resolver can
+   check the CNAME against the DNAME record and validate the signature
+   over the DNAME RR.
 
    Servers MUST be able to answer a query for a synthesized CNAME.  Like
    other query types this invokes the DNAME, and synthesizes the CNAME
-   into the answer.
+   into the answer.  If the server in question is a cache, the
+   synthesized CNAME's TTL SHOULD be equal to the decremented TTL of the
+   cached DNAME.
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 8]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
+   Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
+   equal to the TTL of the corresponding DNAME record (as some older
+   authoritative server implementations set the TTL of synthesized
+   CNAMEs to zero).  A TTL of zero means that the CNAME can be discarded
+   immediately after processing the answer.
 
 3.2.  Server algorithm
 
@@ -441,14 +476,6 @@ Internet-Draft              DNAME Redirection              November 2009
        process can terminate several ways:
 
 
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 8]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
        A.  If the whole of QNAME is matched, we have found the node.
 
            If the data at the node is a CNAME, and QTYPE does not match
@@ -471,6 +498,13 @@ Internet-Draft              DNAME Redirection              November 2009
            4.
 
 
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 9]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
        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.
@@ -497,14 +531,6 @@ Internet-Draft              DNAME Redirection              November 2009
            set the owner of the RR to be QNAME, and not the node with
            the "*" label.  If the data at the node with the "*" label is
            a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 9]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
            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.  Otherwise, Go to step 6.
@@ -527,6 +553,14 @@ Internet-Draft              DNAME Redirection              November 2009
    6.  Using local data only, attempt to add other RRs which may be
        useful to the additional section of the query.  Exit.
 
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 10]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
    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
@@ -553,14 +587,6 @@ Internet-Draft              DNAME Redirection              November 2009
    Recursive caching name servers can encounter data at names below the
    owner name of a DNAME RR, due to a change at the authoritative server
    where data from before and after the change resides in the cache.
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 10]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
    This conflict situation is a transitional phase that ends when the
    old data times out.  The caching name server can opt to store both
    old and new data and treat each as if the other did not exist, or
@@ -580,6 +606,17 @@ Internet-Draft              DNAME Redirection              November 2009
    In [RFC2181], in Section 10.3., the discussion on MX and NS records
    touches on redirection by CNAMEs, but this also holds for DNAMEs.
 
+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 11]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
    Excerpt from 10.3.  MX and NS records (in RFC 2181).
 
            The domain name used as the value of a NS resource record,
@@ -604,19 +641,6 @@ Internet-Draft              DNAME Redirection              November 2009
    would greatly improve the manageability of the IPv6 reverse tree.
    These changes are made explicit below.
 
-
-
-
-
-
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 11]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
    In [RFC3363], the paragraph
 
      "The issues for DNAME in the reverse mapping tree appears to be
@@ -639,6 +663,16 @@ Internet-Draft              DNAME Redirection              November 2009
      "Those nodes are NOT RECOMMENDED to support the experimental
      A6 Resource Record [RFC3363]."
 
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 12]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
 5.  Other Issues with DNAME
 
    There are several issues to be aware of about the use of DNAME.
@@ -665,19 +699,13 @@ Internet-Draft              DNAME Redirection              November 2009
 
    DNAME records can be added, changed and removed in a zone using
    dynamic update transactions.  Adding a DNAME RR to a zone occludes
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 12]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
    any domain names that may exist under the added DNAME.
 
-   A server MUST reject a dynamic update message that attempts to add a
-   DNAME RR at a name that already has a CNAME RR or another DNAME RR
-   associated with that name.
+   A server MUST ignore a dynamic update message that attempts to add a
+   non-DNAME/CNAME RR at a name that already has a DNAME RR associated
+   with that name.  Otherwise, replace the DNAME RR with the DNAME (or
+   CNAME) update RR.  This is similar behavior to dynamic updates to an
+   owner name of a CNAME RR [RFC2136].
 
 5.3.  DNSSEC and DNAME
 
@@ -693,12 +721,20 @@ Internet-Draft              DNAME Redirection              November 2009
    RR and then checking that the CNAME was properly synthesized is
    sufficient proof.
 
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 13]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
 5.3.2.  DNAME Bit in NSEC Type Map
 
    In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
    map SHOULD be checked to see that there was no DNAME that could have
    been applied.  If the DNAME bit in the type bit map is set and the
-   query name is a subdomain of the closest encloser that is asserted,
+   query name is a sub-domain of the closest encloser that is asserted,
    then DNAME substitution should have been done, but the substitution
    has not been done as specified.
 
@@ -715,21 +751,14 @@ Internet-Draft              DNAME Redirection              November 2009
 
    Below are examples of why DNSSEC validators MUST understand DNAME.
    In the examples below, SOA records, wildcard denial NSECs and other
-   material not under discussion has been omitted.
+   material not under discussion has been omitted or shortened.
 
 5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error
 
+   ;; Header: QR AA RCODE=3(NXDOMAIN)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
 
-
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 13]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
-   ;; Header: QR AA DO RCODE=3(NXDOMAIN)
    ;; Question
    foo.bar.example.com. IN A
    ;; Authority
@@ -745,9 +774,23 @@ Internet-Draft              DNAME Redirection              November 2009
    If the DNAME bit had not been set in the NSEC record above then the
    answer would have validated as a correct name error response.
 
+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 14]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
 5.3.4.2.  Valid Name Error Response Involving DNAME in Bitmap
 
-   ;; Header: QR AA DO RCODE=3(NXDOMAIN)
+   ;; Header: QR AA RCODE=3(NXDOMAIN)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
+
    ;; Question
    cee.example.com. IN A
    ;; Authority
@@ -760,7 +803,10 @@ Internet-Draft              DNAME Redirection              November 2009
 
 5.3.4.3.  Response With Synthesized CNAME
 
-   ;; Header: QR AA DO RCODE=0(NOERROR)
+   ;; Header: QR AA RCODE=0(NOERROR)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
+
    ;; Question
    foo.bar.example.com. IN A
    ;; Answer
@@ -777,14 +823,6 @@ Internet-Draft              DNAME Redirection              November 2009
    recursively resolve further to query for the foo.bar.example.net A
    record.
 
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 14]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
 6.  IANA Considerations
 
    The DNAME Resource Record type code 39 (decimal) originally has been
@@ -795,6 +833,14 @@ Internet-Draft              DNAME Redirection              November 2009
 
    DNAME redirects queries elsewhere, which may impact security based on
    policy and the security status of the zone with the DNAME and the
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 15]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
    redirection zone's security status.  For validating resolvers, the
    lowest security status of the links in the chain of CNAME and DNAME
    redirections is applied to the result.
@@ -833,14 +879,6 @@ Internet-Draft              DNAME Redirection              November 2009
 
    [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 15]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
               RFC 2136, April 1997.
 
    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
@@ -851,6 +889,14 @@ Internet-Draft              DNAME Redirection              November 2009
               February 2000.
 
    [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 16]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
               (RR) Types", RFC 3597, September 2003.
 
    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
@@ -892,9 +938,19 @@ Internet-Draft              DNAME Redirection              November 2009
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                 [Page 16]
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 17]
 
-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010
 
 
 Authors' Addresses
@@ -907,7 +963,7 @@ Authors' Addresses
 
    Phone: +1-301-975-8439
    Fax:   +1-301-975-6238
-   EMail: scottr@nist.gov
+   EMail: scottr.nist@gmail.com
 
 
    Wouter Wijngaards
@@ -948,6 +1004,5 @@ Authors' Addresses
 
 
 
-Rose & Wijngaards         Expires May 16, 2010                 [Page 17]
+Rose & Wijngaards       Expires October 22, 2010               [Page 18]
 
-

doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt

@@ -6,13 +6,20 @@
 
 INTERNET-DRAFT                                             A. Gustafsson
                                           Araneus Information Systems Oy
-                                                      September 23, 2009
+                                                       February 24, 2010
 
 Intended status: Draft Standard
 Obsoletes: RFC3597
 
            Handling of Unknown DNS Resource Record (RR) Types
-                  draft-ietf-dnsext-rfc3597-bis-00.txt
+                  draft-ietf-dnsext-rfc3597-bis-02.txt
+
+Abstract
+
+   Extending the Domain Name System (DNS) with new Resource Record (RR)
+   types should not requires changes to name server software.  This
+   document specifies how new RR types are transparently handled by DNS
+   software.
 
 Status of this Memo
 
@@ -36,30 +43,27 @@ Status of this Memo
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors. All rights reserved.
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   Extending the Domain Name System (DNS) with new Resource Record (RR)
-   types should not requires changes to name server software.  This
-   document specifies how new RR types are transparently handled by DNS
-   software.
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document. Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document. Code Components extracted from this document must
 
 
 
-
-Expires March 2010           Standards Track                    [Page 1]
+Expires August 2010          Standards Track                    [Page 1]
 
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
 
 
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
 1.  Introduction
 
    The DNS [RFC1034] is designed to be extensible to support new
@@ -78,10 +82,13 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    types by allowing them to be treated transparently by existing
    implementations.  Thanks to the widespread adoption of that
    specification, much of the DNS is now capable of handling new record
-   types without software changes.
+   types without software changes.  Another development that has
+   simplified the introduction of new DNS RR types is the adoption of a
+   simpler IANA allocation procedure for RR types [RFC5395].
 
    This document is a self-contained revised specification supplanting
-   and obsoleting [RFC3597].
+   and obsoleting RFC 3597, with the aim of allowing the specification
+   to advance on the Standards Track.
 
 2.  Definitions
 
@@ -96,25 +103,24 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    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.
+   In the case of a type whose RDATA format is known to be 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
 
+
+
+Expires August 2010          Standards Track                    [Page 2]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
    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].
-
-
-
-
-Expires March 2010           Standards Track                    [Page 2]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
+   The RDATA section of RRs of unknown type must be treated as
+   unstructured binary data, and must be stored and transmitted without
+   change ([RFC1123], section 6.1.3.5).
 
    To ensure the correct operation of equality comparison (section 6)
    and of the DNSSEC canonical form (section 7) when an RR type is known
@@ -142,7 +148,7 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
 
    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 to ensure interoperability with implementations
+   NXT, SRV, and NAPTR to ensure interoperability with implementations
    predating [RFC3597].
 
    Specifications for new RR types that contain domain names within
@@ -158,76 +164,39 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    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,
+
+
+
+Expires August 2010          Standards Track                    [Page 3]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
    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
-
-
-
-Expires March 2010           Standards Track                    [Page 3]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
-   [RFC1035] to both be unambiguously parsed.
+   [RFC1035] section 5.1 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:
+   sequence of items separated by any combination of tabs and spaces, 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.
+     - 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.
+     - 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.
+     - Zero or more items of hexadecimal data encoding the actual RDATA
+       field, each item 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.
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires March 2010           Standards Track                    [Page 4]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
    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
@@ -251,6 +220,14 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
 
       a.example.   CLASS32     TYPE731         \# 6 abcd (
                                                ef 01 23 45 )
+
+
+
+Expires August 2010          Standards Track                    [Page 4]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
       b.example.   HS          TYPE62347       \# 0
       e.example.   IN          A               \# 4 C0000201
       e.example.   CLASS1      TYPE1           192.0.2.1
@@ -274,16 +251,6 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    records differing only in character case, and not expected to cause
    any problems in practice.
 
-
-
-
-
-
-Expires March 2010           Standards Track                    [Page 5]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
 7.  DNSSEC Considerations
 
    The rules for the DNSSEC canonical form and ordering were updated to
@@ -309,6 +276,14 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    This specification is not believed to cause any new security
    problems, nor to solve any existing ones.
 
+
+
+
+Expires August 2010          Standards Track                    [Page 5]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
 11.  Normative References
 
    [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
@@ -332,14 +307,6 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
                Means for Expressing Location Information in the Domain
                Name System", RFC 1876, January 1996.
 
-
-
-
-Expires March 2010           Standards Track                    [Page 6]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
    [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
                "Dynamic Updates in the Domain Name System (DNS UPDATE)",
                RFC 2136, April 1997.
@@ -362,34 +329,123 @@ draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
    Phone: +358 40 547 2099
    EMail: gson@araneus.fi
 
+Appendix A. Summary of Changes Since RFC3597
+
+   This section summarizes the major changes between RFC3597 and this
 
 
 
+Expires August 2010          Standards Track                    [Page 6]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
 
 
+   document.  In addition to the changes listed below, there has also
+   been a number of editorial changes, such as updates to the text in
+   the Abstract and Introduction to better reflect the current state of
+   implementation, updates to boilerplate text, and minor
+   clarifications.
 
+   The reference to the DNS IANA Considerations BCP (BCP42) has been
+   changed from RFC2929 to the current version, RFC5395.
 
+   Downward references have been eliminated; specifically, the document
+   no longer refers to RFC2163 or RFC2535.
 
+   IP addresses in examples have been changed to use the 192.0.2.0/24
+   range per RFC3330.
 
+   The document no longer specifies changes to the DNSSEC canonical form
+   and ordering, as those changes have now been incorporated into the
+   base DNSSEC specification.
 
+Appendix B. Detailed Change Log
 
+   [NOTE TO RFC EDITOR:  PLEASE REMOVE THIS APPENDIX ON PUBLICATION.]
 
+B.1.  Changes between RFC3597 and -00
 
+   The reference to the DNS IANA Considerations BCP (BCP42) has been
+   changed from RFC2929 to the current version, RFC5395.
 
+   Downward references have been eliminated; specifically, the document
+   no longer refers to RFC2163 or RFC2535.
 
+   IP addresses in examples have been changed to use the 192.0.2.0/24
+   range per RFC3330.
 
+   The document no longer specifies changes to the DNSSEC canonical form
+   and ordering, as those changes have now been incorporated into the
+   base DNSSEC specification.
 
+   There has also been a number of editorial changes, such as updates to
+   the text in the Abstract and Introduction to better reflect the
+   current state of implementation.
 
+B.2.  Changes between -00 and -01
 
+   Moved the Abstract to immediately following the document title.
 
+   Updated boilerplate to the current version.
 
 
 
 
+Expires August 2010          Standards Track                    [Page 7]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
 
 
+   In the Introduction, the text "Another development that has
+   simplified the introduction of new DNS RR types is the adoption of a
+   simpler IANA allocation procedure for RR types" and a reference to
+   [RFC5395] were added.
 
+   In the Introduction, the text "with the aim of allowing the
+   specification to advance on the Standards Track" was added to explain
+   the motivation for the draft.
 
+   In section 2, the text "is class specific" was replaced by "is known
+   to be class specific".
 
-Expires March 2010           Standards Track                    [Page 7]
+   In section 3, the words "That is" were removed so as not to imply
+   that the transparent treatment of RRs of unknown type is only a
+   matter of how the RDATA field is handled.  The remainder of the
+   sentence was rephrased.
+
+   In section 4, the entries for SRV and NAPTR in the list of RR types
+   to decompress were swapped to make the list consistently ordered by
+   ascending numerical RR type.
+
+   References to RFC 1035 and RFC 1123 now include the specific section
+   numbers being referenced.
+
+   A Change History was added as Appendix A.
+
+B.3. Changes between -01 and -02
+
+   In section 5, the term "white space" was replaced by "any combination
+   of tabs and spaces", and the term "word" was replaced by "item", for
+   consistency with RFC1035 terminology.
+
+   In section 5, hyphens were added to mark the beginning of each item
+   in the the list of items comprising the RDATA text representation.
+
+   The Change History was split into a Summary of Changes Since RFC3597
+   (Appendix A) intended to remain in the document when published as an
+   RFC, and a Detailed Change Log (Appendix B) to be deleted on
+   publication.
+
+
+
+
+
+
+
+
+
+
+
+
+Expires August 2010          Standards Track                    [Page 8]
 

doc/draft/draft-ietf-dnsop-default-local-zones-10.txt

@@ -3,12 +3,12 @@
 
 Network Working Group                                         M. Andrews
 Internet-Draft                                                       ISC
-Intended status: BCP                                   November 19, 2009
-Expires: May 23, 2010
+Intended status: BCP                                      March 25, 2010
+Expires: September 26, 2010
 
 
                         Locally-served DNS Zones
-                draft-ietf-dnsop-default-local-zones-09
+                draft-ietf-dnsop-default-local-zones-10
 
 Abstract
 
@@ -41,20 +41,20 @@ Status of this Memo
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on May 23, 2010.
+   This Internet-Draft will expire on September 26, 2010.
 
 Copyright Notice
 
-   Copyright (c) 2009 IETF Trust and the persons identified as the
+   Copyright (c) 2010 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 1]
+Andrews                Expires September 26, 2010               [Page 1]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
    Provisions Relating to IETF Documents
@@ -108,9 +108,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 2]
+Andrews                Expires September 26, 2010               [Page 2]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
 Table of Contents
@@ -121,9 +121,9 @@ Table of Contents
    3.  Changes to Iterative Resolver Behaviour. . . . . . . . . . . .  4
    4.  Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . .  5
      4.1.  RFC1918 Zones  . . . . . . . . . . . . . . . . . . . . . .  5
-     4.2.  RFC3330 Zones  . . . . . . . . . . . . . . . . . . . . . .  6
+     4.2.  RFC3330 and RFC5737 Zones  . . . . . . . . . . . . . . . .  6
      4.3.  Local IPv6 Unicast Addresses . . . . . . . . . . . . . . .  6
-     4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  6
+     4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  7
      4.5.  IPv6 Link Local Addresses  . . . . . . . . . . . . . . . .  7
      4.6.  IPv6 Example Prefix  . . . . . . . . . . . . . . . . . . .  7
    5.  Zones that are Out-Of-Scope  . . . . . . . . . . . . . . . . .  7
@@ -134,18 +134,19 @@ Table of Contents
      9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
      9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
    Appendix A.  Change History [To Be Removed on Publication] . . . . 10
-     A.1.  draft-ietf-dnsop-default-local-zones-09.txt  . . . . . . . 10
-     A.2.  draft-ietf-dnsop-default-local-zones-08.txt  . . . . . . . 10
-     A.3.  draft-ietf-dnsop-default-local-zones-07.txt  . . . . . . . 10
-     A.4.  draft-ietf-dnsop-default-local-zones-06.txt  . . . . . . . 10
-     A.5.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 11
-     A.6.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 11
-     A.7.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 11
-     A.8.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 11
-     A.9.  draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
-     A.10. draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
-     A.11. draft-andrews-full-service-resolvers-03.txt  . . . . . . . 11
-     A.12. draft-andrews-full-service-resolvers-02.txt  . . . . . . . 12
+     A.1.  draft-ietf-dnsop-default-local-zones-10.txt  . . . . . . . 10
+     A.2.  draft-ietf-dnsop-default-local-zones-09.txt  . . . . . . . 10
+     A.3.  draft-ietf-dnsop-default-local-zones-08.txt  . . . . . . . 11
+     A.4.  draft-ietf-dnsop-default-local-zones-07.txt  . . . . . . . 11
+     A.5.  draft-ietf-dnsop-default-local-zones-06.txt  . . . . . . . 11
+     A.6.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 11
+     A.7.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 11
+     A.8.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 11
+     A.9.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 11
+     A.10. draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
+     A.11. draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
+     A.12. draft-andrews-full-service-resolvers-03.txt  . . . . . . . 12
+     A.13. draft-andrews-full-service-resolvers-02.txt  . . . . . . . 12
    Appendix B.  Proposed Status [To Be Removed on Publication]  . . . 12
    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
 
@@ -163,10 +164,9 @@ Table of Contents
 
 
 
-
-Andrews                   Expires May 23, 2010                  [Page 3]
+Andrews                Expires September 26, 2010               [Page 3]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
 1.  Introduction
@@ -220,9 +220,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 4]
+Andrews                Expires September 26, 2010               [Page 4]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
 2.  Effects on sites using RFC 1918 addresses.
@@ -276,9 +276,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 5]
+Andrews                Expires September 26, 2010               [Page 5]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
    The SOA RR is needed to support negative caching [RFC2308] of name
@@ -332,16 +332,17 @@ Internet-Draft          Locally-served DNS Zones           November 2009
 
 
 
-Andrews                   Expires May 23, 2010                  [Page 6]
+Andrews                Expires September 26, 2010               [Page 6]
 
-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010
 
 
-4.2.  RFC3330 Zones
+4.2.  RFC3330 and RFC5737 Zones
 
    The following zones correspond to those address ranges from [RFC3330]
-   that are not expected to appear as source or destination addresses on
-   the public Internet and to not have a unique name to associate with.
+   and [RFC5737] that are not expected to appear as source or
+   destination addresses on the public Internet and to not have a unique
+   name to associate with.
 
    The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
    attempt to discourage any practice to provide a PTR RR for
@@ -357,7 +358,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009
          | 0.IN-ADDR.ARPA               | IPv4 "THIS" NETWORK    |
          | 127.IN-ADDR.ARPA             | IPv4 LOOP-BACK NETWORK |
          | 254.169.IN-ADDR.ARPA         | IPv4 LINK LOCAL        |
-         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST NET          |
+         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST NET 1        |
+         | 100.51.198.IN-ADDR.ARPA      | IPv4 TEST NET 2        |
+         | 113.0.203.IN-ADDR.ARPA       | IPv4 TEST NET 3        |
          | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST         |
          +------------------------------+------------------------+
 
@@ -380,19 +383,20 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    readability and to adhere to line width constraints.  They are not
    parts of the zone names.
 
+
+
+
+
+
+Andrews                Expires September 26, 2010               [Page 7]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
 4.4.  IPv6 Locally Assigned Local Addresses
 
    Section 4.4 of [RFC4193] already required special treatment of:
 
-
-
-
-
-Andrews                   Expires May 23, 2010                  [Page 7]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
                              +--------------+
                              | Zone         |
                              +--------------+
@@ -438,17 +442,16 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    F.E.F.IP6.ARPA may still need to be deployed in the short term if the
    traffic becomes excessive.
 
+
+
+Andrews                Expires September 26, 2010               [Page 8]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
    For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC4193],
    there has been no decision made about whether the Regional Internet
    Registries (RIRs) will provide delegations in this space or not.  If
-
-
-
-Andrews                   Expires May 23, 2010                  [Page 8]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
    they don't, then C.F.IP6.ARPA will need to be added to the list in
    Section 4.4.  If they do, then registries will need to take steps to
    ensure that name servers are provided for these addresses.
@@ -494,17 +497,17 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    DNSSEC validation to succeed for queries in these spaces despite not
    being answered from the delegated servers.
 
+
+
+
+Andrews                Expires September 26, 2010               [Page 9]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
    It is recommended that sites actively using these namespaces secure
    them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
    anchors.  This will protect the clients from accidental import of
-
-
-
-Andrews                   Expires May 23, 2010                  [Page 9]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
    unsigned responses from the Internet.
 
 
@@ -551,16 +554,16 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
               August 2005.
 
+
+
+Andrews                Expires September 26, 2010              [Page 10]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
    [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
               Addresses", RFC 4193, October 2005.
 
-
-
-Andrews                   Expires May 23, 2010                 [Page 10]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
    [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 4291, February 2006.
 
@@ -588,45 +591,54 @@ Internet-Draft          Locally-served DNS Zones           November 2009
    [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
               Reserved for Documentation", RFC 3849, July 2004.
 
+   [RFC5737]  Arkko, J., Cotton, M., and L. Vergoda, "IPv4 Address
+              Blocks Reserved for Documentation", RFC 5737,
+              January 2010.
+
 
 Appendix A.  Change History [To Be Removed on Publication]
 
-A.1.  draft-ietf-dnsop-default-local-zones-09.txt
+A.1.  draft-ietf-dnsop-default-local-zones-10.txt
+
+   added RFC 5737 zones
+
+A.2.  draft-ietf-dnsop-default-local-zones-09.txt
 
    refresh awaiting writeup
 
-A.2.  draft-ietf-dnsop-default-local-zones-08.txt
+
+
+
+
+
+
+Andrews                Expires September 26, 2010              [Page 11]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
+A.3.  draft-ietf-dnsop-default-local-zones-08.txt
 
    editorial, reference updates
 
-A.3.  draft-ietf-dnsop-default-local-zones-07.txt
+A.4.  draft-ietf-dnsop-default-local-zones-07.txt
 
    none, expiry prevention
 
-A.4.  draft-ietf-dnsop-default-local-zones-06.txt
+A.5.  draft-ietf-dnsop-default-local-zones-06.txt
 
    add IPv6 example prefix
 
-
-
-
-
-
-Andrews                   Expires May 23, 2010                 [Page 11]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
-A.5.  draft-ietf-dnsop-default-local-zones-05.txt
+A.6.  draft-ietf-dnsop-default-local-zones-05.txt
 
    none, expiry prevention
 
-A.6.  draft-ietf-dnsop-default-local-zones-04.txt
+A.7.  draft-ietf-dnsop-default-local-zones-04.txt
 
    Centrally Assigned Local addresses -> Non-Locally Assigned Local
    address
 
-A.7.  draft-ietf-dnsop-default-local-zones-03.txt
+A.8.  draft-ietf-dnsop-default-local-zones-03.txt
 
    expanded section 4 descriptions
 
@@ -636,44 +648,40 @@ A.7.  draft-ietf-dnsop-default-local-zones-03.txt
 
    Revised language.
 
-A.8.  draft-ietf-dnsop-default-local-zones-02.txt
+A.9.  draft-ietf-dnsop-default-local-zones-02.txt
 
    RNAME now "nobody.invalid."
 
    Revised language.
 
-A.9.  draft-ietf-dnsop-default-local-zones-01.txt
+A.10.  draft-ietf-dnsop-default-local-zones-01.txt
 
    Revised impact description.
 
    Updated to reflect change in IP6.INT status.
 
-A.10.  draft-ietf-dnsop-default-local-zones-00.txt
+A.11.  draft-ietf-dnsop-default-local-zones-00.txt
 
    Adopted by DNSOP.
 
    "Author's Note" re-titled "Zones that are Out-Of-Scope"
 
+
+
+Andrews                Expires September 26, 2010              [Page 12]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
    Add note that these zone are expected to seed the IANA registry.
 
    Title changed.
 
-A.11.  draft-andrews-full-service-resolvers-03.txt
+A.12.  draft-andrews-full-service-resolvers-03.txt
 
    Added "Proposed Status".
 
-
-
-
-
-
-
-Andrews                   Expires May 23, 2010                 [Page 12]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
-A.12.  draft-andrews-full-service-resolvers-02.txt
+A.13.  draft-andrews-full-service-resolvers-02.txt
 
    Added 0.IN-ADDR.ARPA.
 
@@ -692,7 +700,7 @@ Author's Address
    Redwood City, CA  94063
    US
 
-   Email: Mark_Andrews@isc.org
+   Email: marka@isc.org
 
 
 
@@ -716,14 +724,5 @@ Author's Address
 
 
 
-
-
-
-
-
-
-
-
-Andrews                   Expires May 23, 2010                 [Page 13]
+Andrews                Expires September 26, 2010              [Page 13]
 
-

doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt

@@ -0,0 +1,504 @@
+
+
+
+Domain Name System Operations                              W. Wijngaards
+Internet-Draft                                                O. Kolkman
+Intended status: Standards Track                              NLnet Labs
+Expires: August 26, 2010                               February 22, 2010
+
+
+                  DNSSEC Trust Anchor History Service
+                draft-ietf-dnsop-dnssec-trust-history-01
+
+Abstract
+
+   When DNS validators have trusted keys, but have been offline for a
+   longer period, key rollover will fail and they are stuck with stale
+   trust anchors.  History service allows validators to query for older
+   DNSKEY RRsets and pick up the rollover trail where they left off.
+
+Requirements 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 [RFC2119].
+
+Status of This Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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 26, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 1]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+1.  Introduction
+
+   This memo defines a trust history service for DNS validators -- the
+   component in a resolver that performs DNSSEC [RFC4034] validation,
+   validator for short.
+
+   A validator that has been offline or missed an (emergency) rollover
+   can use this service to reconfigure themselves with the current
+   trust-anchor.  Using a newly defined resource record (RR) that links
+   old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY
+   RRsets and checks they form a chain to the latest key (see
+   Section 2).  The lists of old DNSKEYS, linked with the TALINK RRs, do
+   not necessarily need to be published in the zone for which the DNSKEY
+   history is being maintained but can be published in any DNS domain.
+   We will call the entity that offers the trust history the History
+   Provider.  The choice of the History Provider is made by the
+   maintainer of the validator, possibly based on a hint provided, using
+   the TALINK, by the zone owner.
+
+   The algorithm that the validator uses to construct a history and
+   reconfigure a new key is detailed in Section 3.  The algorithms for
+   how providers of trust history can fetch the DNSKEY data as published
+   by the zone they track and publish that are explained in Section 4.
+
+2.  The  TALINK Resource Record
+
+   The DNS Resource Record type TALINK (decimal 58) ties the elements of
+   a linked list of DNSKEY RRs together.
+
+   The rdata consists of two domain names.  The first name is the start,
+   or previous name, and the other name the end or next name in the
+   list.  The empty label '.' is used at the endpoints of the list.
+
+   The presentation format is the two domain names.  The wire encoding
+   is the two domain names, with no compression so the type can be
+   treated according to [RFC3597].  The list is a double linked list,
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 2]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   because this empowers low memory hosts to perform consistency checks.
+
+3.  Trust History Lookup
+
+   This is the algorithm that a validator uses to detect and resolve the
+   situation in which a trust-anchor is out of sync with the DNSKEYs
+   published by a zone owner.  The algorithm uses the TALINK RR type
+   which is used to link various old DNSKEYs as published by the History
+   Provider, to arrive from the outdated configured Trust Anchor to one
+   that matches the current DNSKEY.  The TALINK RR type is defined in
+   Section 2.
+
+   When the algorithm below results in failure the trust history cannot
+   be build and a new trust anchor will need to be re-configured using
+   another mechanism.
+
+   Step 1:  The validator performs a DNSKEY lookup to the target zone,
+      which looks like any other initial DNSKEY lookup that the
+      validator needs to match a trust anchor to the currently used
+      DNSKEY RR set.  If the keyset verifies with the trust anchor
+      currently held, the trust-anchor is not out of sync.  Otherwise,
+      store the DNSKEY RR set as result.  The algorithm will
+      successfully build a linked list to this DNSKEY RR, or delete the
+      trust point, or fail.
+
+      All nameservers (the ones authoritative for the zone or the
+      upstream resolver caches when the validator is not full resolver)
+      SHOULD be checked to make sure the DNSKEY RR sets are the same.
+      The results can differ if a key-rollover is in progress and not
+      all nameservers are in sync yet.  This case can be detected by
+      checking that the older keyset signs the newer and take the newer
+      as result keyset.  The keysets are distinguished by the average
+      over the middle of the inception and expiration dates of the
+      signatures that are validated by the keyset itself.  Otherwise,
+      the history lookup fails.  If the check fails then the
+      inconsistency may be the result of spoofing, or compromise of
+      (DNS) infrastructure elements.
+
+   Step 2:  Fetch the trust history list end points.  Perform a query of
+      QTYPE TALINK and QNAME the domain name that is configured to be
+      the History Provider for the particular domain you are trying to
+      update the trust-anchor for.
+
+   Step 3:  Go backwards through the trust history list as provided by
+      the TALINK linked list.  Verify that the keyset validly signs the
+      next keyset.  This is [RFC4034] validation, but the RRSIG
+      expiration date is ignored.  [Editor note: Are we shure that there
+      are no server implementations that will not serve expired RRSIG,
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 3]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+      are such 'smart' servers allowed by the specs?  In other words do
+      we need clarification in the DNSSEC-updates document?]  Replace
+      the owner domain name with the target zone name for verification.
+      One of the keys that signs the next keyset MUST have the SEP bit
+      set.  The middle of inception and expiration date from the valid
+      signature MUST be older than that of the signature that validates
+      the next keys in the list.  Query type TALINK to get previous and
+      next locations.
+
+      If all SEP keys have the REVOKE flag set at this step, and the
+      keyset is signed by all SEP keys, then continue but store that the
+      end result is that the trust point is deleted, see Section 5
+      [RFC5011].
+
+      If all SEP keys are of an unknown algorithm at this step, continue
+      and at the next step, when you verify if the keyset signs validly:
+      if false, continue with result a failure, if true, continue with
+      the end result that the trust point is deleted.  Thus, the keysets
+      with unknown algorithms are stepped over with an end result of
+      failure because the validator cannot determine if unknown
+      algorithm signatures are valid, until the oldest keyset with
+      unknown algorithms is signed by a known algorithm and the result
+      is set to deletion and step 3 continues to a known key.
+
+   Step 4:  When the trust anchor currently held by the validator
+      verifies the keyset, the algorithm is done.  The validator SHOULD
+      store the result on stable storage.  Use the new trust anchor for
+      validation (if using [RFC5011], put it in state VALID).
+
+4.  Trust History Tracker
+
+   External trackers can poll the target zone DNSKEY RRset regularly.
+   Ignore date changes in the RRSIG.  Ignore changes to keys with no SEP
+   flag.  Copy the newly polled DNSKEY RRset and RRSIGs, change the
+   owner name to a new name at the history location.  Publish the new
+   RRset and TALINK records to make it the last element in the list.
+   Update the TALINK that advertises the first and last name.
+
+   Integrated into the rollover, the keys are stored in the history and
+   the TALINK is updated when a new key is used in the rollover process.
+   This gives the TALINK and new historical key time to propagate.
+
+   The signer can support trust history.  Trust history key sets need
+   only contain SEP keys.  To use older signers, move historical RRSIGs
+   to another file.  Sign the zone, including the TALINK and DNSKEY
+   records.  Append the historical RRSIGs to the result.  Signing the
+   zone like this obviates the need for changes to signer and server
+   software.
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 4]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+5.  Example
+
+   In this example example.com is the History Provider for example.net.
+   The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a copy
+   and paste of the data from example.net.
+
+   $ORIGIN example.com.
+   example.com. TALINK h0.example.com. h2.example.com.
+
+   h0 TALINK . h1.example.com.
+   h0 DNSKEY ...
+   h0 RRSIG ...
+
+   h1 TALINK h0.example.com. h2.example.com.
+   h1 DNSKEY ...
+   h1 RRSIG ...
+
+   h2 TALINK h1.example.com. .
+   h2 DNSKEY ...
+   h2 RRSIG ...
+
+   The example.net zone can advertise the example.com History Provider
+   by providing the TALINK shown here at example.com at the apex of the
+   example.net zone.  The TALINK at example.com is then not needed.
+
+6.  Deployment
+
+   The trust history is advertised with TALINK RRs at the zone apex.
+   These represent alternative history sources, that can be searched in
+   turn.  The TALINK at the zone apex contains the first and last name
+   of the list of historical keys.
+
+   The historical list of keys grows perpetually.  Since most validators
+   have recent keys, their processing time remains similar as the list
+   grows.  If validators no longer have trust in the keys then they need
+   no longer be published.  The oldest key entries can be omitted from
+   the list to shorten it.
+
+   The validator decides how long it trusts a key.  A recommendation
+   from the zone owner can be configured for keys of that zone, or
+   recommendations per algorithm and key size can be used (e.g. see
+   [NIST800-57]).  If a key is older than that, trust history lookup
+   fails with it and the trust point can be considered deleted.  This
+   assumes the validator has decided on a security policy and also can
+   take actions when the update of the trust anchor fails.  Without such
+   policy, or if the alternative is no DNSSEC, the approach below can be
+   used.
+
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 5]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   In general, the decision can be that any key - no matter how old or
+   how small - is better than no security.  The validator then never
+   considers a key too old, and the lookup algorithm becomes an
+   unsecured update mechanism at the time where the key can be trivially
+   broken.  The history provider SHOULD provide these broken keys to
+   facilitate clients performing the unsecured update.  If a key can not
+   be trivially broken then it provides a non-trivial amount of security
+   that the history lookup algorithm uses to get the current keys.
+   Conceivably after the update the result is stored on stable storage
+   and the client is thereafter safe - it performs a leap of faith.  The
+   validator operator can opt for this set up after considering the
+   trade-off between loss of DNSSEC, loss of connectivity, and the
+   argument that perceived security is worse than no security.
+
+   The history lookup can be used on its own.  Then, the trust history
+   is used whenever the key rolls over and no polling is performed.
+   This has associated risks, in that the immediate rollover without
+   timeout that it provides could be abused, and certainly when taken
+   together with leap-of-faith such systems SHOULD inform their user
+   that the key has changed and urge them to do immediate checks.
+   Initially we put a hold down timer on such rollovers to mitigate the
+   abuse risks but these make following normal rollovers impossible.
+
+   If a validator is also using [RFC5011] for the target zone, then the
+   trust history algorithm SHOULD only be invoked if the [RFC5011]
+   algorithm failed due to the inability to perform probes.  This is the
+   case when the last [RFC5011] successful probe was more than 30 days
+   ago.  If a new key has been announced, invoke the history if no 2
+   probes succeeded during the add hold-down time and there was no
+   successful probe after the add hold-down time passed.  Therefore the
+   time of the last successful probe MUST be stored on stable storage.
+
+   For testing the potentially very infrequently used lookup, the
+   following SHOULD be implemented.  For the test the lookup is
+   triggered manually by allowing the system to be given a particular
+   keyset with a last successful lookup date in the past and a test
+   History Provider.  The test History Provider provides access to a
+   generated back-dated test history.
+
+7.  Security Considerations
+
+   The History Provider only provides copies of old data.  If that
+   historic data is altered or withheld the lookup algorithm fails
+   because of validation errors in Step 3 of the algorithm.  If the
+   History provider or a Man in the Middle Adversary (MIMA) has access
+   to the original private keys (through theft, cryptanalisis, or
+   otherwise), history can be altered without failure of the algorithm.
+   Below we only consider MIMAs and assume the History Provider is a
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 6]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   trusted party.
+
+   Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of
+   TALINK and DNSKEY data, can present some alternate history.  However
+   the DNSKEY RR set trusted that the history should arrive at is
+   already fixed by step 1.  If an attempt is made to subvert the
+   algorithm at step 2 or 3, then the result keyset can not be replaced
+   by another keyset unnoticed.
+
+   To change the keyset trusted as the outcome, the step 1 data has to
+   be spoofed and the key held by the validator (or a newer historic
+   key) has to be compromised.  Unless such spoof is targeted to a
+   specific victim, a spoof of the step 1 result has a high visibility.
+   Since most of the validators that receive the spoof have an up-to-
+   date trust anchor most validators that would receive this spoof
+   return validation failure for data from the zone that contains the
+   DNSKEYs.  An adversary will therefore have to target the attack to
+   validators that are in the process of an update.  Since validators do
+   not announce that they use trust history lookup until step 2
+   adversaries will not be able to select the validators.
+
+   A spoof of data in steps 2 and 3, together with a compromised (old)
+   key, can result in a downgrade.  At steps 2 and 3 a faked trust point
+   deletion or algorithm rollover can be inserted in a fake history.
+   This avoids the high visibility of spoofing the current key (see
+   previous paragraph) and downgrades to insecure.
+
+   Finally there is the case that one of the keys published by the
+   History Providers has been compromised.  Since someone spoofing at
+   step 1 of the lookup algorithm and presenting some fake history to a
+   compromised key, of course does not include key revocations and does
+   extend the history to contain the compromised key, it therefore is
+   not really useful for a History Provider to remove the key from the
+   published history.  That only makes lookups fail for those validators
+   who are not under attack.  Useful action could be to update
+   validators using some other means.
+
+   Rollover with [RFC5011] revokes keys after use.  If a History
+   Provider is used, then such revoked keys SHOULD be used to perform
+   history tracking and history lookup.  The old keys that the validator
+   starts with and final current keys MUST NOT be trusted if they are
+   revoked.
+
+   Depending on choices by the validator operator, it may accept a leap-
+   of-faith, and possibly allow non-hold-down rollovers.  Although this
+   allows very fast emergency rollover if all clients are known to do
+   trust-history lookups without the RFC5011-algorithm, it also allows
+   an attacker with the private key to attempt to take over a zone
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 7]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   quickly and get validators to roll to a trust anchor of the
+   attacker's choosing.
+
+   The SEP bit is checked to make sure that control over the KSK is
+   necessary to change the keyset for the target zone.
+
+   The algorithm can be used to get the inception and expiration times
+   of signatures on the current keyset, a clock.  A MIMA can attempt to
+   shorten history and put back that clock, but the algorithm attempts
+   to make this difficult to target and highly visible to others.
+
+   If the clock of the validator can be influenced, then setting it
+   forward is unlikely to give advantage, but setting it backward
+   enables a replay attack of old DNSSEC data and signatures.  This
+   vulnerability exists also in plain DNSSEC.
+
+8.  IANA Considerations
+
+   Resource record type TALINK has been defined using RFC5395 expert
+   review, it has RR type number 58 (decimal).
+
+9.  Acknowledgments
+
+   Thanks to the people who provided review and suggestions, Joe Abley,
+   George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark
+   Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil,
+   Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and
+   Matthijs Mekking.
+
+10.  References
+
+10.1.  Informative References
+
+   [NIST800-57]  Barker, E., Barker, W., Burr, W., Polk, W., and M.
+                 Smid, "Recommendations for Key Management", NIST
+                 SP 800-57, March 2007.
+
+   [RFC5011]     StJohns, M., "Automated Updates of DNS Security
+                 (DNSSEC) Trust Anchors", RFC 5011, September 2007.
+
+10.2.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3597]     Gustafsson, A., "Handling of Unknown DNS Resource
+                 Record (RR) Types", RFC 3597, September 2003.
+
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 8]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   [RFC4034]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
+                 Rose, "Resource Records for the DNS Security
+                 Extensions", RFC 4034, March 2005.
+
+Authors' Addresses
+
+   Wouter Wijngaards
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   EMail: wouter@nlnetlabs.nl
+
+
+   Olaf Kolkman
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   EMail: olaf@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 9]
+

doc/draft/draft-kerr-ixfr-only-01.txt

@@ -0,0 +1,336 @@
+
+
+
+DNSext Working Group                                             O. Sury
+Internet-Draft                                                    CZ.NIC
+Updates: 1995 (if approved)                                 S. Kerr, Ed.
+Intended status: Standards Track                                     ISC
+Expires: August 30, 2010                               February 26, 2010
+
+
+               IXFR-ONLY to Prevent IXFR Fallback to AXFR
+                        draft-kerr-ixfr-only-01
+
+Abstract
+
+   This documents proposes a new QTYPE (Query pseudo RRtype) for the
+   Domain Name System (DNS).  IXFR-ONLY is a variant of IXFR (RFC 1995)
+   that allows an authoritative server to incrementally update zone
+   content from another (primary) server without falling back from IXFR
+   to AXFR.  This way, alternate peers can be contacted more quickly and
+   convergence of zone content may be achieved much faster in important,
+   resilient operational scenarios.
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and 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 30, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 1]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
+   2.  IXFR Server Side  . . . . . . . . . . . . . . . . . . . . . . . 4
+   3.  IXFR Client Side  . . . . . . . . . . . . . . . . . . . . . . . 4
+   4.  Applicability of IXFR-ONLY  . . . . . . . . . . . . . . . . . . 5
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 2]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+1.  Introduction
+
+   For large DNS zones, RFC 1995 [RFC1995] defines Incremental Zone
+   Transfer (IXFR), which allows only to transfer the changed portion(s)
+   of a zone.
+
+   In the document, an IXFR client and an IXFR server is defined as in
+   RFC 1995 [RFC1995], 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.
+
+   IXFR is an efficient way to transfer changes in zones from IXFR
+   servers to IXFR clients.  However, when an IXFR client has multiple
+   IXFR servers for a single zone, it is possible that not all IXFR
+   servers have the zone with same serial number for that zone.  In this
+   case, if an IXFR client attempts an IXFR from an IXFR server which
+   does not have zone with the serial number used by the IXFR client,
+   the IXFR server will fall back to a full zone transfer (AXFR) when it
+   has a version of the zone with serial number greater than the serial
+   requested by the IXFR client.
+
+   For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for
+   a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the
+   same zone.  An IXFR client that has the zone with serial number 2
+   which sends an IXFR request to IXFR server NS2 will get a full zone
+   transfer (AXFR) of the zone at serial number 3.  This is because NS2
+   does not know the zone with serial number 2, and therefore does not
+   know what the differences are between zone with serial number 2 and
+   3.
+
+   If the IXFR client in this example had known to send the query to
+   IXFR server NS1, then it could have gotten an incremental transfer
+   (IXFR).  But IXFR clients can only know what the latest version of
+   the zone is at a IXFR server (this information is available via an
+   SOA query).
+
+   The IXFR-ONLY query type provides a way for the IXFR client to ask
+   each IXFR server to return an error instead of sending the current
+   version of the zone via full zone transfer (AXFR).  By using this, a
+   IXFR client can check each IXFR server until it finds one able to
+   provide IXFR.
+
+1.1.  Requirements 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 [RFC2119].
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 3]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+2.  IXFR Server Side
+
+   A IXFR server receiving a DNS message requesting IXFR-ONLY will reply
+   as described in RFC 1995 [RFC1995] if it is able to produce an IXFR
+   for the serial number requested.
+
+   If the IXFR server is is not able to reply with an IXFR it MUST NOT
+   reply with an AXFR unless AXFR result is smaller than IXFR result.
+   Instead, it MUST reply with RCODE CannotIXFR. (!FIXME)
+
+   If the IXFR result is larger than an AXFR, then an IXFR server MAY
+   reply with an AXFR result instead.  This is an optimization, and IXFR
+   servers MAY only reply with AXFR if they are certain that the reply
+   using AXFR is smaller than an equivalent IXFR reply.
+
+
+3.  IXFR Client Side
+
+   An IXFR client who wishes to use IXFR-ONLY will send a message to one
+   of the IXFR servers.  The format is exactly the same as for IXFR,
+   except the IXFR-ONLY QTYPE code is used instead of the IXFR QTYPE
+   code.
+
+   If the IXFR server replies with IXFR, then the IXFR client is done.
+
+   If the IXFR server replies with an RCODE of CannotIXFR, then the IXFR
+   client proceeds on to a different IXFR server.  In this case the IXFR
+   server implements IXFR-ONLY, but does not have information about zone
+   with the serial number requested.
+
+   If the IXFR server replies with any RCODE other than CannotIXFR or
+   NoError, then the IXFR client proceeds on to a different IXFR server.
+   In this case the IXFR server does not implement IXFR-ONLY.
+
+   If the IXFR client attempts IXFR-ONLY to each IXFR server and none of
+   them reply with an incremental transfer (IXFR), then it should
+   attempt an IXFR as described in RFC 1995 [RFC1995] to each of the
+   IXFR servers which replied with an RCODE other than CannotIXFR or
+   NoError.
+
+   The method described above allows IXFR clients to operate normally in
+   situatians where some of the IXFR servers do support IXFR-ONLY, and
+   some who do not.  IXFR clients MAY remember which IXFR servers
+   support IXFR-ONLY and query those IXFR servers first.  However since
+   IXFR servers may change software or even run a mix of software, IXFR
+   clients MUST attempt to query each IXFR server periodically when they
+   attempt to get new versions of a zone.
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 4]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+   Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
+   given IXFR server, if this is known in advance.  These IXFR servers
+   are treated as if they replied with an RCODE other than CannotIXFR or
+   NoError, although no query with IXFR-ONLY is actually sent.
+
+
+4.  Applicability of IXFR-ONLY
+
+   Implementations SHOULD allow IXFR clients to disable IXFR-ONLY
+   completely.
+
+   Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
+   specific zone.  This may be useful for small zones, where fallback to
+   AXFR is cheap, or in other cases where IXFR-ONLY is causing problems.
+
+   Usage of IXFR-ONLY may cause IXFR clients to prefer particular IXFR
+   servers, by shifting load to ones that support IXFR-ONLY.  If this a
+   problem, then administrators can disable IXFR-ONLY in implementations
+   that allow it.
+
+   If a IXFR client has a single IXFR server for a zone, it SHOULD use
+   IXFR rather than IXFR-ONLY.
+
+
+5.  IANA Considerations
+
+   IANA allocates the new IXFR-ONLY QTYPE, which means "incremental
+   transfer only".  IANA allocates the CannotIXFR RCODE, which means
+   "Server cannot provide IXFR for zone".
+
+
+6.  Security Considerations
+
+   IXFR-ONLY may be used by someone to get information about the state
+   of IXFR servers by providing a quick and efficient way to check which
+   versions of a zone each IXFR server supports.  Zones should be
+   secured via TSIG [RFC2845] to prevent unauthorized information
+   exposure.  However, even administrators of IXFR servers may not want
+   this information given to IXFR clients, in which case they will need
+   to disable IXFR-ONLY.
+
+
+7.  Normative References
+
+   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              August 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 5]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+
+Authors' Addresses
+
+   Ondrej Sury
+   CZ.NIC
+   Americka 23
+   120 00 Praha 2
+   CZ
+
+   Phone: +420 222 745 110
+   Email: ondrej.sury@nic.cz
+
+
+   Shane Kerr (editor)
+   ISC
+   Bennebrokestraat 17-I
+   1015 PE Amsterdam
+   NL
+
+   Phone: +31 64 6336297
+   Email: shane@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 6]
+

doc/private/SRCID

@@ -1,6 +1,6 @@
-# $Id: SRCID,v 1.17.4.16 2009/12/09 02:21:07 tbox Exp $
+# $Id: SRCID,v 1.17.4.53 2010/04/21 05:15:57 tbox Exp $
 # 
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
 #
-SRCID="( $Date: 2009/12/09 02:21:07 $ )"
+SRCID="( $Date: 2010/04/21 05:15:57 $ )"

lib/dns/api

@@ -1,3 +1,3 @@
 LIBINTERFACE = 38
-LIBREVISION = 0
+LIBREVISION = 1
 LIBAGE = 0

lib/dns/include/dns/rdataset.h

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009, 2010  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: rdataset.h,v 1.51.18.9 2009/01/19 23:46:16 tbox Exp $ */
+/* $Id: rdataset.h,v 1.51.18.11 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_RDATASET_H
 #define DNS_RDATASET_H 1
@@ -104,6 +104,9 @@ typedef struct dns_rdatasetmethods {
 						 dns_rdataset_t *rdataset,
 						 dns_rdatasetadditional_t type,
 						 dns_rdatatype_t qtype);
+	void			(*settrust)(dns_rdataset_t *rdataset,
+					    dns_trust_t trust);
+	void			(*expire)(dns_rdataset_t *rdataset);
 } dns_rdatasetmethods_t;
 
 #define DNS_RDATASET_MAGIC	       ISC_MAGIC('D','N','S','R')
@@ -592,6 +595,19 @@ dns_rdataset_putadditional(dns_acache_t *acache,
  *			  information for 'rdataset.'
  */
 
+void
+dns_rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust);
+/*%<
+ * Set the trust of the 'rdataset' to trust in any in the backing database.
+ * The local trust level of 'rdataset' is also set.
+ */
+
+void
+dns_rdataset_expire(dns_rdataset_t *rdataset);
+/*%<
+ * Mark the rdataset to be expired in the backing database.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RDATASET_H */

lib/dns/include/dns/resolver.h

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009, 2010  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: resolver.h,v 1.40.18.13 2009/09/24 23:46:07 tbox Exp $ */
+/* $Id: resolver.h,v 1.40.18.15 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_RESOLVER_H
 #define DNS_RESOLVER_H 1
@@ -491,6 +491,48 @@ dns_resolver_getzeronosoattl(dns_resolver_t *resolver);
 void
 dns_resolver_setzeronosoattl(dns_resolver_t *resolver, isc_boolean_t state);
 
+void
+dns_resolver_addbadcache(dns_resolver_t *resolver, dns_name_t *name,
+			 dns_rdatatype_t type, isc_time_t *expire);
+/*%<
+ * Add a entry to the bad cache for <name,type> that will expire at 'expire'.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ * \li	name to be valid.
+ */
+
+isc_boolean_t
+dns_resolver_getbadcache(dns_resolver_t *resolver, dns_name_t *name,
+			 dns_rdatatype_t type, isc_time_t *now);
+/*%<
+ * Check to see if there is a unexpired entry in the bad cache for
+ * <name,type>.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ * \li	name to be valid.
+ */
+
+void
+dns_resolver_flushbadcache(dns_resolver_t *resolver, dns_name_t *name);
+/*%<
+ * Flush the bad cache of all entries at 'name' if 'name' is non NULL.
+ * Flush the entire bad cache if 'name' is NULL.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ */
+
+void
+dns_resolver_printbadcache(dns_resolver_t *resolver, FILE *fp);
+/*%
+ * Print out the contents of the bad cache to 'fp'.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RESOLVER_H */

lib/dns/include/dns/result.h

@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  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.h,v 1.104.10.6 2005/06/17 02:04:32 marka Exp $ */
+/* $Id: result.h,v 1.104.10.8 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_RESULT_H
 #define DNS_RESULT_H 1
@@ -147,8 +147,11 @@
 #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_NOTMASTER			(ISC_RESULTCLASS_DNS + 105)
+#define DNS_R_BROKENCHAIN		(ISC_RESULTCLASS_DNS + 106)
 
-#define DNS_R_NRESULTS			104	/*%< Number of results */
+#define DNS_R_NRESULTS			107	/*%< Number of results */
 
 /*
  * DNS wire format rcodes.

lib/dns/include/dns/validator.h

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009, 2010  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.13 2009/01/19 00:36:28 marka Exp $ */
+/* $Id: validator.h,v 1.27.18.15 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_VALIDATOR_H
 #define DNS_VALIDATOR_H 1
@@ -151,6 +151,8 @@ struct dns_validator {
 	isc_boolean_t			mustbesecure;
 	unsigned int			dlvlabels;
 	unsigned int			depth;
+	unsigned int			authcount;
+	unsigned int			authfail;
 };
 
 /*%

lib/dns/ncache.c

@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  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.36.18.5 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -478,6 +478,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	NULL,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 

lib/dns/rbtdb.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  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.59 2009/11/26 23:46:11 tbox Exp $ */
+/* $Id: rbtdb.c,v 1.196.18.61 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -414,6 +414,8 @@ static isc_result_t rdataset_putadditional(dns_acache_t *acache,
 					   dns_rdataset_t *rdataset,
 					   dns_rdatasetadditional_t type,
 					   dns_rdatatype_t qtype);
+static void rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust);
+static void rdataset_expire(dns_rdataset_t *rdataset);
 
 static dns_rdatasetmethods_t rdataset_methods = {
 	rdataset_disassociate,
@@ -426,7 +428,9 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	rdataset_getnoqname,
 	rdataset_getadditional,
 	rdataset_setadditional,
-	rdataset_putadditional
+	rdataset_putadditional,
+	rdataset_settrust,
+	rdataset_expire
 };
 
 static void rdatasetiter_destroy(dns_rdatasetiter_t **iteratorp);
@@ -5823,6 +5827,36 @@ rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name,
 	return (ISC_R_SUCCESS);
 }
 
+static void
+rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust) {
+	dns_rbtdb_t *rbtdb = rdataset->private1;
+	dns_rbtnode_t *rbtnode = rdataset->private2;
+	rdatasetheader_t *header = rdataset->private3;
+
+	header--;
+	NODE_LOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+		  isc_rwlocktype_write);
+	header->trust = rdataset->trust = trust;
+	NODE_UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+		  isc_rwlocktype_write);
+}
+
+static void
+rdataset_expire(dns_rdataset_t *rdataset) {
+	dns_rbtdb_t *rbtdb = rdataset->private1;
+	dns_rbtnode_t *rbtnode = rdataset->private2;
+	rdatasetheader_t *header = rdataset->private3;
+
+	header--;
+	NODE_LOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+		  isc_rwlocktype_write);
+	header->ttl = 0;
+	header->attributes |= RDATASET_ATTR_STALE;
+	rbtnode->dirty = 1;
+	NODE_UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+		  isc_rwlocktype_write);
+}
+
 /*
  * Rdataset Iterator Methods
  */

lib/dns/rdatalist.c

@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  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.28.18.5 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -43,6 +43,8 @@ static dns_rdatasetmethods_t methods = {
 	isc__rdatalist_getnoqname,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 

lib/dns/rdataset.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009, 2010  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: rdataset.c,v 1.72.18.7 2009/01/19 23:46:15 tbox Exp $ */
+/* $Id: rdataset.c,v 1.72.18.9 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -179,6 +179,8 @@ static dns_rdatasetmethods_t question_methods = {
 	NULL,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
@@ -707,3 +709,22 @@ dns_rdataset_putadditional(dns_acache_t *acache,
 	return (ISC_R_FAILURE);
 }
 
+void
+dns_rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust) {
+	REQUIRE(DNS_RDATASET_VALID(rdataset));
+	REQUIRE(rdataset->methods != NULL);
+
+	if (rdataset->methods->settrust != NULL)
+		(rdataset->methods->settrust)(rdataset, trust);
+	else
+		rdataset->trust = trust;
+}
+
+void
+dns_rdataset_expire(dns_rdataset_t *rdataset) {
+	REQUIRE(DNS_RDATASET_VALID(rdataset));
+	REQUIRE(rdataset->methods != NULL);
+
+	if (rdataset->methods->expire != NULL)
+		(rdataset->methods->expire)(rdataset);
+}

lib/dns/rdataslab.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009, 2010  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.10 2009/01/19 23:46:15 tbox Exp $ */
+/* $Id: rdataslab.c,v 1.35.18.12 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -405,6 +405,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	NULL,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 

lib/dns/resolver.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  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: resolver.c,v 1.284.18.97 2009/11/25 23:46:52 tbox Exp $ */
+/* $Id: resolver.c,v 1.284.18.101 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -318,6 +318,18 @@ typedef struct alternate {
 	ISC_LINK(struct alternate)	link;
 } alternate_t;
 
+typedef struct dns_badcache dns_badcache_t;
+struct dns_badcache {
+	dns_badcache_t *	next;
+	dns_rdatatype_t 	type;
+	isc_time_t		expire;
+	unsigned int		hashval;
+	dns_name_t		name;
+};
+#define DNS_BADCACHE_SIZE 1021
+#define DNS_BADCACHE_TTL(fctx) \
+	(((fctx)->res->lame_ttl > 30 ) ? (fctx)->res->lame_ttl : 30)
+
 struct dns_resolver {
 	/* Unlocked. */
 	unsigned int			magic;
@@ -361,6 +373,13 @@ struct dns_resolver {
 	unsigned int			activebuckets;
 	isc_boolean_t			priming;
 	unsigned int			spillat;	/* clients-per-query */
+
+	/* Bad cache. */
+	dns_badcache_t	**		badcache;
+	unsigned int			badcount;
+	unsigned int			badhash;
+	unsigned int			badsweep;
+
 	/* Locked by primelock. */
 	dns_fetch_t *			primefetch;
 	/* Locked by nlock. */
@@ -390,7 +409,7 @@ 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 badcache);
 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,
@@ -1088,7 +1107,7 @@ process_sendevent(resquery_t *query, isc_event_t *event) {
 		if (result != ISC_R_SUCCESS)
 			fctx_done(fctx, result, __LINE__);
 		else
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_FALSE);
 	}
 }
 
@@ -1946,7 +1965,7 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 		if (result != ISC_R_SUCCESS)
 			fctx_done(fctx, result, __LINE__);
 		else
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_FALSE);
 	}
 }
 
@@ -2008,7 +2027,7 @@ fctx_finddone(isc_task_t *task, isc_event_t *event) {
 	dns_adb_destroyfind(&find);
 
 	if (want_try)
-		fctx_try(fctx);
+		fctx_try(fctx, ISC_FALSE);
 	else if (want_done)
 		fctx_done(fctx, ISC_R_FAILURE, __LINE__);
 	else if (bucket_empty)
@@ -2371,7 +2390,7 @@ isstrictsubdomain(dns_name_t *name1, dns_name_t *name2) {
 }
 
 static isc_result_t
-fctx_getaddresses(fetchctx_t *fctx) {
+fctx_getaddresses(fetchctx_t *fctx, isc_boolean_t badcache) {
 	dns_rdata_t rdata = DNS_RDATA_INIT;
 	isc_result_t result;
 	dns_resolver_t *res;
@@ -2590,12 +2609,24 @@ fctx_getaddresses(fetchctx_t *fctx) {
 			 */
 			result = DNS_R_WAIT;
 		} else {
+			isc_time_t expire;
+			isc_interval_t i;
 			/*
 			 * We've lost completely.  We don't know any
 			 * addresses, and the ADB has told us it can't get
 			 * them.
 			 */
 			FCTXTRACE("no addresses");
+			isc_interval_set(&i, DNS_BADCACHE_TTL(fctx), 0);
+			result = isc_time_nowplusinterval(&expire, &i);
+			if (badcache &&
+			    (fctx->type == dns_rdatatype_dnskey ||
+			     fctx->type == dns_rdatatype_dlv ||
+			     fctx->type == dns_rdatatype_ds) &&
+			     result == ISC_R_SUCCESS)
+				dns_resolver_addbadcache(fctx->res,
+							 &fctx->name,
+							 fctx->type, &expire);
 			result = ISC_R_FAILURE;
 		}
 	} else {
@@ -2817,7 +2848,7 @@ fctx_nextaddress(fetchctx_t *fctx) {
 }
 
 static void
-fctx_try(fetchctx_t *fctx) {
+fctx_try(fetchctx_t *fctx, isc_boolean_t badcache) {
 	isc_result_t result;
 	dns_adbaddrinfo_t *addrinfo;
 
@@ -2835,7 +2866,7 @@ fctx_try(fetchctx_t *fctx) {
 		fctx_cleanupaltfinds(fctx);
 		fctx_cleanupforwaddrs(fctx);
 		fctx_cleanupaltaddrs(fctx);
-		result = fctx_getaddresses(fctx);
+		result = fctx_getaddresses(fctx, badcache);
 		if (result == DNS_R_WAIT) {
 			/*
 			 * Sleep waiting for addresses.
@@ -2995,7 +3026,7 @@ fctx_timeout(isc_task_t *task, isc_event_t *event) {
 			/*
 			 * Keep trying.
 			 */
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_FALSE);
 	}
 
 	isc_event_free(&event);
@@ -3165,7 +3196,7 @@ fctx_start(isc_task_t *task, isc_event_t *event) {
 		if (result != ISC_R_SUCCESS)
 			fctx_done(fctx, result, __LINE__);
 		else
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_FALSE);
 	} else if (bucket_empty)
 		empty_bucket(res);
 }
@@ -3740,6 +3771,8 @@ validated(isc_task_t *task, isc_event_t *event) {
 
 	LOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 
+	isc_stdtime_get(&now);
+
 	/*
 	 * If chaining, we need to make sure that the right result code is
 	 * returned, and that the rdatasets are bound.
@@ -3785,36 +3818,80 @@ validated(isc_task_t *task, isc_event_t *event) {
 		FCTXTRACE("validation failed");
 		fctx->valfail++;
 		fctx->vresult = vevent->result;
-		result = ISC_R_NOTFOUND;
-		if (vevent->rdataset != NULL)
-			result = dns_db_findnode(fctx->cache, vevent->name,
-						 ISC_TRUE, &node);
-		if (result == ISC_R_SUCCESS)
-			(void)dns_db_deleterdataset(fctx->cache, node, NULL,
-						    vevent->type, 0);
-		if (result == ISC_R_SUCCESS && vevent->sigrdataset != NULL)
-			(void)dns_db_deleterdataset(fctx->cache, node, NULL,
-						    dns_rdatatype_rrsig,
-						    vevent->type);
-		if (result == ISC_R_SUCCESS)
-			dns_db_detachnode(fctx->cache, &node);
-		result = vevent->result;
+		if (fctx->vresult != DNS_R_BROKENCHAIN) {
+			result = ISC_R_NOTFOUND;
+			if (vevent->rdataset != NULL)
+				result = dns_db_findnode(fctx->cache,
+							 vevent->name,
+							 ISC_TRUE, &node);
+			if (result == ISC_R_SUCCESS)
+				(void)dns_db_deleterdataset(fctx->cache, node,
+							     NULL,
+							    vevent->type, 0);
+			if (result == ISC_R_SUCCESS &&
+			     vevent->sigrdataset != NULL)
+				(void)dns_db_deleterdataset(fctx->cache, node,
+							    NULL,
+							    dns_rdatatype_rrsig,
+							    vevent->type);
+			if (result == ISC_R_SUCCESS)
+				dns_db_detachnode(fctx->cache, &node);
+		}
+		if (fctx->vresult == DNS_R_BROKENCHAIN && !negative) {
+			/*
+			 * Cache the data as pending for later validation.
+			 */
+			result = ISC_R_NOTFOUND;
+			if (vevent->rdataset != NULL)
+				result = dns_db_findnode(fctx->cache,
+							 vevent->name,
+							 ISC_TRUE, &node);
+			if (result == ISC_R_SUCCESS) {
+				(void)dns_db_addrdataset(fctx->cache, node,
+							 NULL, now,
+							 vevent->rdataset, 0,
+							 NULL);
+			}
+			if (result == ISC_R_SUCCESS &&
+			    vevent->sigrdataset != NULL)
+				(void)dns_db_addrdataset(fctx->cache, node,
+							 NULL, now,
+							 vevent->sigrdataset,
+							 0, NULL);
+			if (result == ISC_R_SUCCESS)
+				dns_db_detachnode(fctx->cache, &node);
+		}
+		result = fctx->vresult;
 		add_bad(fctx, addrinfo, result, badns_validation);
 		isc_event_free(&event);
 		UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 		INSIST(fctx->validator == NULL);
 		fctx->validator = ISC_LIST_HEAD(fctx->validators);
-		if (fctx->validator != NULL) {
+		if (fctx->validator != NULL)
 			dns_validator_send(fctx->validator);
-		} else if (sentresponse)
+		else if (sentresponse)
 			fctx_done(fctx, result, __LINE__); /* Locks bucket. */
-		else
-			fctx_try(fctx);			/* Locks bucket. */
+		else if (result == DNS_R_BROKENCHAIN) {
+			isc_result_t tresult;
+			isc_time_t expire;
+			isc_interval_t i;
+
+			isc_interval_set(&i, DNS_BADCACHE_TTL(fctx), 0);
+			tresult = isc_time_nowplusinterval(&expire, &i);
+			if (negative &&
+			    (fctx->type == dns_rdatatype_dnskey ||
+			     fctx->type == dns_rdatatype_dlv ||
+			     fctx->type == dns_rdatatype_ds) &&
+			     tresult == ISC_R_SUCCESS)
+				dns_resolver_addbadcache(fctx->res,
+							 &fctx->name,
+							 fctx->type, &expire);
+			fctx_done(fctx, result, __LINE__); /* Locks bucket. */
+		} else
+			fctx_try(fctx, ISC_TRUE);	   /* Locks bucket. */
 		return;
 	}
 
-	isc_stdtime_get(&now);
-
 	if (negative) {
 		dns_rdatatype_t covers;
 		FCTXTRACE("nonexistence validation OK");
@@ -4125,11 +4202,19 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
 			rdataset->ttl = res->view->maxcachettl;
 
 		/*
-		 * If this rrset is in a secure domain, do DNSSEC validation
-		 * for it, unless it is glue.
+		 * If this RRset is in a secure domain, is in bailiwick,
+		 * and is not glue, attempt DNSSEC validation.	(We do not
+		 * attempt to validate glue or out-of-bailiwick data--even
+		 * though there might be some performance benefit to doing
+		 * so--because it makes it simpler and safer to ensure that
+		 * records from a secure domain are only cached if validated
+		 * within the context of a query to the domain that owns
+		 * them.)
 		 */
-		if (secure_domain && rdataset->trust != dns_trust_glue) {
+		if (secure_domain && rdataset->trust != dns_trust_glue &&
+		    !EXTERNAL(rdataset)) {
 			dns_trust_t trust;
+
 			/*
 			 * RRSIGs are validated as part of validating the
 			 * type they cover.
@@ -4166,22 +4251,6 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
 			}
 
 			/*
-			 * Reject out of bailiwick additional records
-			 * without RRSIGs as they can't possibly validate
-			 * as "secure" and as we will never never want to
-			 * store these as "answers" after validation.
-			 */
-			if (rdataset->trust == dns_trust_additional &&
-			    sigrdataset == NULL && EXTERNAL(rdataset))
-				continue;
-
-			/*
-			 * XXXMPA: If we store as "answer" after validating
-			 * then we need to do bailiwick processing and
-			 * also need to track whether RRsets are in or
-			 * out of bailiwick.  This will require a another
-			 * pending trust level.
-			 *
 			 * Cache this rdataset/sigrdataset pair as
 			 * pending data.  Track whether it was additional
 			 * or not.
@@ -5290,9 +5359,7 @@ answer_response(fetchctx_t *fctx) {
 						/*
 						 * This data is outside of
 						 * our query domain, and
-						 * may only be cached if it
-						 * comes from a secure zone
-						 * and validates.
+						 * may not be cached.
 						 */
 						rdataset->attributes |=
 						    DNS_RDATASETATTR_EXTERNAL;
@@ -5599,7 +5666,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 		/*
 		 * Try again.
 		 */
-		fctx_try(fctx);
+		fctx_try(fctx, ISC_FALSE);
 	} else {
 		unsigned int n;
 		dns_rdataset_t *nsrdataset = NULL;
@@ -6339,7 +6406,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 		/*
 		 * Try again.
 		 */
-		fctx_try(fctx);
+		fctx_try(fctx, ISC_FALSE);
 	} else if (resend) {
 		/*
 		 * Resend (probably with changed options).
@@ -6400,6 +6467,27 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 /***
  *** Resolver Methods
  ***/
+static void
+destroy_badcache(dns_resolver_t *res) {
+	dns_badcache_t *bad, *next;
+	unsigned int i;
+
+	if (res->badcache != NULL) {
+		for (i = 0; i < res->badhash; i++)
+			for (bad = res->badcache[i]; bad != NULL;
+			     bad = next) {
+				next = bad->next;
+				isc_mem_put(res->mctx, bad, sizeof(*bad) +
+					    bad->name.length);
+				res->badcount--;
+			}
+		isc_mem_put(res->mctx, res->badcache,
+			    sizeof(*res->badcache) * res->badhash);
+		res->badcache = NULL;
+		res->badhash = 0;
+		INSIST(res->badcount == 0);
+	}
+}
 
 static void
 destroy(dns_resolver_t *res) {
@@ -6437,6 +6525,7 @@ destroy(dns_resolver_t *res) {
 		isc_mem_put(res->mctx, a, sizeof(*a));
 	}
 	dns_resolver_reset_algorithms(res);
+	destroy_badcache(res);
 	dns_resolver_resetmustbesecure(res);
 #if USE_ALGLOCK
 	isc_rwlock_destroy(&res->alglock);
@@ -6560,6 +6649,10 @@ dns_resolver_create(dns_view_t *view,
 	ISC_LIST_INIT(res->alternates);
 	res->udpsize = RECV_BUFFER_SIZE;
 	res->algorithms = NULL;
+	res->badcache = NULL;
+	res->badcount = 0;
+	res->badhash = 0;
+	res->badsweep = 0;
 	res->mustbesecure = NULL;
 	res->spillatmin = res->spillat = 10;
 	res->spillatmax = 100;
@@ -7390,6 +7483,256 @@ dns_resolver_getudpsize(dns_resolver_t *resolver) {
 	return (resolver->udpsize);
 }
 
+void
+dns_resolver_flushbadcache(dns_resolver_t *resolver, dns_name_t *name) {
+	unsigned int i;
+	dns_badcache_t *bad, *prev, *next;
+
+	REQUIRE(VALID_RESOLVER(resolver));
+
+	LOCK(&resolver->lock);
+	if (resolver->badcache == NULL)
+		goto unlock;
+
+	if (name != NULL) {
+		isc_time_t now;
+		isc_result_t result;
+		result = isc_time_now(&now);
+		if (result != ISC_R_SUCCESS)
+			isc_time_settoepoch(&now);
+		i = dns_name_hash(name, ISC_FALSE) % resolver->badhash;
+		prev = NULL;
+		for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+			int n;
+			next = bad->next;
+			n = isc_time_compare(&bad->expire, &now);
+			if (n < 0 || dns_name_equal(name, &bad->name)) {
+				if (prev == NULL)
+					resolver->badcache[i] = bad->next;
+				else
+					prev->next = bad->next;
+				isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+					    bad->name.length);
+				resolver->badcount--;
+			} else
+				prev = bad;
+		}
+	} else
+		destroy_badcache(resolver);
+
+ unlock:
+	UNLOCK(&resolver->lock);
+
+}
+
+static void
+resizehash(dns_resolver_t *resolver, isc_time_t *now, isc_boolean_t grow) {
+	unsigned int newsize;
+	dns_badcache_t **new, *bad, *next;
+	unsigned int i;
+
+	if (grow)
+		newsize = resolver->badhash * 2 + 1;
+	else
+		newsize = (resolver->badhash - 1) / 2;
+
+	new = isc_mem_get(resolver->mctx,
+			  sizeof(*resolver->badcache) * newsize);
+	if (new == NULL)
+		return;
+	memset(new, 0, sizeof(*resolver->badcache) * newsize);
+	for (i = 0; i < resolver->badhash; i++) {
+		for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+			next = bad->next;
+			if (isc_time_compare(&bad->expire, now) < 0) {
+				isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+					    bad->name.length);
+				resolver->badcount--;
+			} else {
+				bad->next = new[bad->hashval % newsize];
+				new[bad->hashval % newsize] = bad;
+			}
+		}
+	}
+	isc_mem_put(resolver->mctx, resolver->badcache,
+		    sizeof(*resolver->badcache) * resolver->badhash);
+	resolver->badhash = newsize;
+	resolver->badcache = new;
+}
+
+void
+dns_resolver_addbadcache(dns_resolver_t *resolver, dns_name_t *name,
+			 dns_rdatatype_t type, isc_time_t *expire)
+{
+	isc_time_t now;
+	isc_result_t result = ISC_R_SUCCESS;
+	unsigned int i, hashval;
+	dns_badcache_t *bad, *prev, *next;
+
+	REQUIRE(VALID_RESOLVER(resolver));
+
+	LOCK(&resolver->lock);
+	if (resolver->badcache == NULL) {
+		resolver->badcache = isc_mem_get(resolver->mctx,
+						 sizeof(*resolver->badcache) *
+						 DNS_BADCACHE_SIZE);
+		if (resolver->badcache == NULL) {
+			result = ISC_R_NOMEMORY;
+			goto cleanup;
+		}
+		resolver->badhash = DNS_BADCACHE_SIZE;
+		memset(resolver->badcache, 0, sizeof(*resolver->badcache) *
+		       resolver->badhash);
+	}
+
+	result = isc_time_now(&now);
+	if (result != ISC_R_SUCCESS)
+		isc_time_settoepoch(&now);
+	hashval = dns_name_hash(name, ISC_FALSE);
+	i = hashval % resolver->badhash;
+	prev = NULL;
+	for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+		next = bad->next;
+		if (bad->type == type && dns_name_equal(name, &bad->name))
+			break;
+		if (isc_time_compare(&bad->expire, &now) < 0) {
+			if (prev == NULL)
+				resolver->badcache[i] = bad->next;
+			else
+				prev->next = bad->next;
+			isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+				    bad->name.length);
+			resolver->badcount--;
+		} else
+			prev = bad;
+	}
+	if (bad == NULL) {
+		isc_buffer_t buffer;
+		bad = isc_mem_get(resolver->mctx, sizeof(*bad) + name->length);
+		if (bad == NULL) {
+			result = ISC_R_NOMEMORY;
+			goto cleanup;
+		}
+		bad->type = type;
+		bad->hashval = hashval;
+		isc_buffer_init(&buffer, bad + 1, name->length);
+		dns_name_init(&bad->name, NULL);
+		dns_name_copy(name, &bad->name, &buffer);
+		bad->next = resolver->badcache[i];
+		resolver->badcache[i] = bad;
+		resolver->badcount++;
+		if (resolver->badcount > resolver->badhash * 8)
+			resizehash(resolver, &now, ISC_TRUE);
+		if (resolver->badcount < resolver->badhash * 2 &&
+		    resolver->badhash > DNS_BADCACHE_SIZE)
+			resizehash(resolver, &now, ISC_FALSE);
+	}
+	bad->expire = *expire;
+ cleanup:
+	UNLOCK(&resolver->lock);
+}
+
+isc_boolean_t
+dns_resolver_getbadcache(dns_resolver_t *resolver, dns_name_t *name,
+			 dns_rdatatype_t type, isc_time_t *now)
+{
+	dns_badcache_t *bad, *prev, *next;
+	isc_boolean_t answer = ISC_FALSE;
+	unsigned int i;
+
+	REQUIRE(VALID_RESOLVER(resolver));
+
+	LOCK(&resolver->lock);
+	if (resolver->badcache == NULL)
+		goto unlock;
+
+	i = dns_name_hash(name, ISC_FALSE) % resolver->badhash;
+	prev = NULL;
+	for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+		next = bad->next;
+		/*
+		 * Search the hash list. Clean out expired records as we go.
+		 */
+		if (isc_time_compare(&bad->expire, now) < 0) {
+			if (prev != NULL)
+				prev->next = bad->next;
+			else
+				resolver->badcache[i] = bad->next;
+			isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+				    bad->name.length);
+			resolver->badcount--;
+			continue;
+		}
+		if (bad->type == type && dns_name_equal(name, &bad->name)) {
+			answer = ISC_TRUE;
+			break;
+		}
+		prev = bad;
+	}
+
+	/*
+	 * Slow sweep to clean out stale records.
+	 */
+	i = resolver->badsweep++ % resolver->badhash;
+	bad = resolver->badcache[i];
+	if (bad != NULL && isc_time_compare(&bad->expire, now) < 0) {
+		resolver->badcache[i] = bad->next;
+		isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+			    bad->name.length);
+		resolver->badcount--;
+	}
+
+ unlock:
+	UNLOCK(&resolver->lock);
+	return (answer);
+}
+
+void
+dns_resolver_printbadcache(dns_resolver_t *resolver, FILE *fp) {
+	char namebuf[DNS_NAME_FORMATSIZE];
+	char typebuf[DNS_RDATATYPE_FORMATSIZE];
+	dns_badcache_t *bad, *next, *prev;
+	isc_time_t now;
+	unsigned int i;
+	isc_uint64_t t;
+
+	LOCK(&resolver->lock);
+	fprintf(fp, ";\n; Bad cache\n;\n");
+
+	if (resolver->badcache == NULL)
+		goto unlock;
+
+	TIME_NOW(&now);
+	for (i = 0; i < resolver->badhash; i++) {
+		prev = NULL;
+		for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+			next = bad->next;
+			if (isc_time_compare(&bad->expire, &now) < 0) {
+				if (prev != NULL)
+					prev->next = bad->next;
+				else
+					resolver->badcache[i] = bad->next;
+				isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+					    bad->name.length);
+				resolver->badcount--;
+				continue;
+			}
+			prev = bad;
+			dns_name_format(&bad->name, namebuf, sizeof(namebuf));
+			dns_rdatatype_format(bad->type, typebuf,
+					     sizeof(typebuf));
+			t = isc_time_microdiff(&bad->expire, &now);
+			t /= 1000;
+			fprintf(fp, "; %s/%s [ttl "
+				"%" ISC_PLATFORM_QUADFORMAT "u]\n",
+				namebuf, typebuf, t);
+		}
+	}
+
+ unlock:
+	UNLOCK(&resolver->lock);
+}
+
 static void
 free_algorithm(void *node, void *arg) {
 	unsigned char *algorithms = node;

lib/dns/result.c

@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  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.115.10.9 2010/02/26 23:46:37 tbox Exp $ */
 
 /*! \file */
 
@@ -155,7 +155,11 @@ 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 */
+
+	"not master",			       /*%< 105 DNS_R_NOTMASTER */
+	"broken trust chain",		       /*%< 106 DNS_R_BROKENCHAIN */
 };
 
 static const char *rcode_text[DNS_R_NRCODERESULTS] = {

lib/dns/sdb.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  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.19 2009/06/26 06:25:20 marka Exp $ */
+/* $Id: sdb.c,v 1.45.18.21 2010/02/26 23:46:37 tbox Exp $ */
 
 /*! \file */
 
@@ -1374,6 +1374,8 @@ static dns_rdatasetmethods_t methods = {
 	isc__rdatalist_getnoqname,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 

lib/dns/sdlz.c

@@ -1,5 +1,5 @@
 /*
- * Portions Copyright (C) 2005-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005-2007, 2009, 2010  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.14 2009/06/26 06:25:20 marka Exp $ */
+/* $Id: sdlz.c,v 1.2.2.16 2010/02/26 23:46:37 tbox Exp $ */
 
 /*! \file */
 
@@ -1198,6 +1198,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	isc__rdatalist_getnoqname,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 

lib/dns/validator.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  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.c,v 1.119.18.50 2009/11/25 04:50:25 marka Exp $ */
+/* $Id: validator.c,v 1.119.18.54 2010/04/21 04:23:47 marka Exp $ */
 
 /*! \file */
 
@@ -170,9 +170,16 @@ static inline void
 markanswer(dns_validator_t *val) {
 	validator_log(val, ISC_LOG_DEBUG(3), "marking as answer");
 	if (val->event->rdataset != NULL)
-		val->event->rdataset->trust = dns_trust_answer;
+		dns_rdataset_settrust(val->event->rdataset, dns_trust_answer);
 	if (val->event->sigrdataset != NULL)
-		val->event->sigrdataset->trust = dns_trust_answer;
+		dns_rdataset_settrust(val->event->sigrdataset,
+				      dns_trust_answer);
+}
+
+static inline void
+marksecure(dns_validatorevent_t *event) {
+	dns_rdataset_settrust(event->rdataset, dns_trust_secure);
+	dns_rdataset_settrust(event->sigrdataset, dns_trust_secure);
 }
 
 static void
@@ -337,7 +344,7 @@ fetch_callback_validator(isc_task_t *task, isc_event_t *event) {
 		if (eresult == ISC_R_CANCELED)
 			validator_done(val, eresult);
 		else
-			validator_done(val, DNS_R_NOVALIDKEY);
+			validator_done(val, DNS_R_BROKENCHAIN);
 	}
 	want_destroy = exit_check(val);
 	UNLOCK(&val->lock);
@@ -407,7 +414,7 @@ dsfetched(isc_task_t *task, isc_event_t *event) {
 		if (eresult == ISC_R_CANCELED)
 			validator_done(val, eresult);
 		else
-			validator_done(val, DNS_R_NOVALIDDS);
+			validator_done(val, DNS_R_BROKENCHAIN);
 	}
 	want_destroy = exit_check(val);
 	UNLOCK(&val->lock);
@@ -547,10 +554,16 @@ keyvalidated(isc_task_t *task, isc_event_t *event) {
 		if (result != DNS_R_WAIT)
 			validator_done(val, result);
 	} else {
+		if (eresult != DNS_R_BROKENCHAIN) {
+			if (dns_rdataset_isassociated(&val->frdataset))
+				dns_rdataset_expire(&val->frdataset);
+			if (dns_rdataset_isassociated(&val->fsigrdataset))
+				dns_rdataset_expire(&val->fsigrdataset);
+		}
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "keyvalidated: got %s",
 			      isc_result_totext(eresult));
-		validator_done(val, eresult);
+		validator_done(val, DNS_R_BROKENCHAIN);
 	}
 	want_destroy = exit_check(val);
 	UNLOCK(&val->lock);
@@ -597,10 +610,16 @@ dsvalidated(isc_task_t *task, isc_event_t *event) {
 		if (result != DNS_R_WAIT)
 			validator_done(val, result);
 	} else {
+		if (eresult != DNS_R_BROKENCHAIN) {
+			if (dns_rdataset_isassociated(&val->frdataset))
+				dns_rdataset_expire(&val->frdataset);
+			if (dns_rdataset_isassociated(&val->fsigrdataset))
+				dns_rdataset_expire(&val->fsigrdataset);
+		}
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "dsvalidated: got %s",
 			      isc_result_totext(eresult));
-		validator_done(val, eresult);
+		validator_done(val, DNS_R_BROKENCHAIN);
 	}
 	want_destroy = exit_check(val);
 	UNLOCK(&val->lock);
@@ -802,6 +821,8 @@ authvalidated(isc_task_t *task, isc_event_t *event) {
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "authvalidated: got %s",
 			      isc_result_totext(result));
+		if (result == DNS_R_BROKENCHAIN)
+			val->authfail++;
 		if (result == ISC_R_CANCELED)
 			validator_done(val, result);
 		else {
@@ -867,6 +888,7 @@ authvalidated(isc_task_t *task, isc_event_t *event) {
  * \li	DNS_R_NCACHENXRRSET
  * \li	DNS_R_NXRRSET
  * \li	DNS_R_NXDOMAIN
+ * \li	DNS_R_BROKENCHAIN
  */
 static inline isc_result_t
 view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
@@ -876,9 +898,12 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
 	dns_rdata_t rdata = DNS_RDATA_INIT;
 	isc_result_t result;
 	unsigned int options;
+	isc_time_t now;
 	char buf1[DNS_NAME_FORMATSIZE];
 	char buf2[DNS_NAME_FORMATSIZE];
 	char buf3[DNS_NAME_FORMATSIZE];
+	char namebuf[DNS_NAME_FORMATSIZE];
+	char typebuf[DNS_RDATATYPE_FORMATSIZE];
 
 	if (dns_rdataset_isassociated(&val->frdataset))
 		dns_rdataset_disassociate(&val->frdataset);
@@ -888,6 +913,16 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
 	if (val->view->zonetable == NULL)
 		return (ISC_R_CANCELED);
 
+	if (isc_time_now(&now) == ISC_R_SUCCESS &&
+	    dns_resolver_getbadcache(val->view->resolver, name, type, &now)) {
+
+		dns_name_format(name, namebuf, sizeof(namebuf));
+		dns_rdatatype_format(type, typebuf, sizeof(typebuf));
+		validator_log(val, ISC_LOG_INFO, "bad cache hit (%s/%s)",
+			      namebuf, typebuf);
+		return (DNS_R_BROKENCHAIN);
+	}
+
 	options = DNS_DBFIND_PENDINGOK;
 	if (type == dns_rdatatype_dlv)
 		options |= DNS_DBFIND_COVERINGNSEC;
@@ -896,6 +931,7 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
 	result = dns_view_find(val->view, name, type, 0, options,
 			       ISC_FALSE, NULL, NULL, foundname,
 			       &val->frdataset, &val->fsigrdataset);
+
 	if (result == DNS_R_NXDOMAIN) {
 		if (dns_rdataset_isassociated(&val->frdataset))
 			dns_rdataset_disassociate(&val->frdataset);
@@ -1240,7 +1276,8 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
 		/*
 		 * We don't know anything about this key.
 		 */
-		result = create_fetch(val, &siginfo->signer, dns_rdatatype_dnskey,
+		result = create_fetch(val, &siginfo->signer,
+				      dns_rdatatype_dnskey,
 				      fetch_callback_validator, "get_key");
 		if (result != ISC_R_SUCCESS)
 			return (result);
@@ -1255,7 +1292,8 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
 		 * This key doesn't exist.
 		 */
 		result = DNS_R_CONTINUE;
-	}
+	} else if (result == DNS_R_BROKENCHAIN)
+		return (result);
 
 	if (dns_rdataset_isassociated(&val->frdataset) &&
 	    val->keyset != &val->frdataset)
@@ -1503,8 +1541,7 @@ validate(dns_validator_t *val, isc_boolean_t resume) {
 				      "looking for noqname proof");
 			return (nsecvalidate(val, ISC_FALSE));
 		} else if (result == ISC_R_SUCCESS) {
-			event->rdataset->trust = dns_trust_secure;
-			event->sigrdataset->trust = dns_trust_secure;
+			marksecure(event);
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "marking as secure");
 			return (result);
@@ -1680,8 +1717,7 @@ dlv_validatezonekey(dns_validator_t *val) {
 			      "no RRSIG matching DLV key");
 	}
 	if (result == ISC_R_SUCCESS) {
-		val->event->rdataset->trust = dns_trust_secure;
-		val->event->sigrdataset->trust = dns_trust_secure;
+		marksecure(val->event);
 		validator_log(val, ISC_LOG_DEBUG(3), "marking as secure");
 		return (result);
 	} else if (result == ISC_R_NOMORE && !supported_algorithm) {
@@ -1782,8 +1818,7 @@ validatezonekey(dns_validator_t *val) {
 				keynode = nextnode;
 			}
 			if (result == ISC_R_SUCCESS) {
-				event->rdataset->trust = dns_trust_secure;
-				event->sigrdataset->trust = dns_trust_secure;
+				marksecure(event);
 				validator_log(val, ISC_LOG_DEBUG(3),
 					      "signed by trusted key; "
 					      "marking as secure");
@@ -1810,11 +1845,14 @@ validatezonekey(dns_validator_t *val) {
 			 */
 			dns_name_format(val->event->name, namebuf,
 					sizeof(namebuf));
-			validator_log(val, ISC_LOG_DEBUG(2),
+			validator_log(val, ISC_LOG_NOTICE,
 				      "unable to find a DNSKEY which verifies "
 				      "the DNSKEY RRset and also matches one "
 				      "of specified trusted-keys for '%s'",
 				      namebuf);
+			validator_log(val, ISC_LOG_NOTICE,
+				      "please check the 'trusted-keys' for "
+				      "'%s' in named.conf.", namebuf);
 			return (DNS_R_NOVALIDKEY);
 		}
 
@@ -1875,7 +1913,8 @@ validatezonekey(dns_validator_t *val) {
 				dns_rdataset_disassociate(&val->fsigrdataset);
 			validator_log(val, ISC_LOG_DEBUG(2), "no DS record");
 			return (DNS_R_NOVALIDSIG);
-		}
+		} else if (result == DNS_R_BROKENCHAIN)
+			return (result);
 	}
 
 	/*
@@ -2024,8 +2063,7 @@ validatezonekey(dns_validator_t *val) {
 			      "no RRSIG matching DS key");
 	}
 	if (result == ISC_R_SUCCESS) {
-		event->rdataset->trust = dns_trust_secure;
-		event->sigrdataset->trust = dns_trust_secure;
+		marksecure(event);
 		validator_log(val, ISC_LOG_DEBUG(3), "marking as secure");
 		return (result);
 	} else if (result == ISC_R_NOMORE && !supported_algorithm) {
@@ -2231,6 +2269,7 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 						  "nsecvalidate");
 			if (result != ISC_R_SUCCESS)
 				return (result);
+			val->authcount++;
 			return (DNS_R_WAIT);
 
 		}
@@ -2252,8 +2291,7 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 				      "noqname proof found");
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "marking as secure");
-			val->event->rdataset->trust = dns_trust_secure;
-			val->event->sigrdataset->trust = dns_trust_secure;
+			marksecure(val->event);
 			return (ISC_R_SUCCESS);
 		}
 		validator_log(val, ISC_LOG_DEBUG(3),
@@ -2284,6 +2322,8 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 		return (ISC_R_SUCCESS);
 	}
 
+	if (val->authfail != 0 && val->authcount == val->authfail)
+		return (DNS_R_BROKENCHAIN);
 	validator_log(val, ISC_LOG_DEBUG(3),
 		      "nonexistence proof(s) not found");
 	val->attributes |= VALATTR_INSECURITY;
@@ -2315,6 +2355,58 @@ check_ds(dns_validator_t *val, dns_name_t *name, dns_rdataset_t *rdataset) {
 	return (ISC_FALSE);
 }
 
+static void
+dlvvalidated(isc_task_t *task, isc_event_t *event) {
+	dns_validatorevent_t *devent;
+	dns_validator_t *val;
+	isc_result_t eresult;
+	isc_boolean_t want_destroy;
+
+	UNUSED(task);
+	INSIST(event->ev_type == DNS_EVENT_VALIDATORDONE);
+
+	devent = (dns_validatorevent_t *)event;
+	val = devent->ev_arg;
+	eresult = devent->result;
+
+	isc_event_free(&event);
+	dns_validator_destroy(&val->subvalidator);
+
+	INSIST(val->event != NULL);
+
+	validator_log(val, ISC_LOG_DEBUG(3), "in dlvvalidated");
+	LOCK(&val->lock);
+	if (CANCELED(val)) {
+		validator_done(val, ISC_R_CANCELED);
+	} else if (eresult == ISC_R_SUCCESS) {
+		validator_log(val, ISC_LOG_DEBUG(3),
+			      "dlvset with trust %d", val->frdataset.trust);
+		dns_rdataset_clone(&val->frdataset, &val->dlv);
+		val->havedlvsep = ISC_TRUE;
+		if (dlv_algorithm_supported(val))
+			dlv_validator_start(val);
+		else {
+			markanswer(val);
+			validator_done(val, ISC_R_SUCCESS);
+		}
+	} else {
+		if (eresult != DNS_R_BROKENCHAIN) {
+			if (dns_rdataset_isassociated(&val->frdataset))
+				dns_rdataset_expire(&val->frdataset);
+			if (dns_rdataset_isassociated(&val->fsigrdataset))
+				dns_rdataset_expire(&val->fsigrdataset);
+		}
+		validator_log(val, ISC_LOG_DEBUG(3),
+			      "dlvvalidated: got %s",
+			      isc_result_totext(eresult));
+		validator_done(val, DNS_R_BROKENCHAIN);
+	}
+	want_destroy = exit_check(val);
+	UNLOCK(&val->lock);
+	if (want_destroy)
+		destroy(val);
+}
+
 /*%
  * Callback from fetching a DLV record.
  *
@@ -2534,6 +2626,24 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) {
 			      namebuf);
 		result = view_find(val, dlvname, dns_rdatatype_dlv);
 		if (result == ISC_R_SUCCESS) {
+			if (DNS_TRUST_PENDING(val->frdataset.trust) &&
+			    dns_rdataset_isassociated(&val->fsigrdataset))
+			{
+				dns_fixedname_init(&val->fname);
+				dns_name_copy(dlvname,
+					      dns_fixedname_name(&val->fname),
+					      NULL);
+				result = create_validator(val,
+						dns_fixedname_name(&val->fname),
+							  dns_rdatatype_dlv,
+							  &val->frdataset,
+							  &val->fsigrdataset,
+							  dlvvalidated,
+							  "finddlvsep");
+				if (result != ISC_R_SUCCESS)
+					return (result);
+				return (DNS_R_WAIT);
+			}
 			if (val->frdataset.trust < dns_trust_secure)
 				return (DNS_R_NOVALIDSIG);
 			val->havedlvsep = ISC_TRUE;
@@ -2584,6 +2694,7 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) {
  * \li	DNS_R_NOVALIDSIG
  * \li	DNS_R_NOVALIDNSEC
  * \li	DNS_R_NOTINSECURE
+ * \li	DNS_R_BROKENCHAIN
  */
 static isc_result_t
 proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
@@ -2599,20 +2710,20 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 	if (val->havedlvsep)
 		dns_name_copy(dns_fixedname_name(&val->dlvsep), secroot, NULL);
 	else {
+		unsigned int labels;
 		dns_name_copy(val->event->name, secroot, NULL);
 		/*
 		 * If this is a response to a DS query, we need to look in
 		 * the parent zone for the trust anchor.
 		 */
-		if (val->event->type == dns_rdatatype_ds &&
-		    dns_name_countlabels(secroot) > 1U)
-			dns_name_split(secroot, 1, NULL, secroot);
+
+		labels = dns_name_countlabels(secroot);
+		if (val->event->type == dns_rdatatype_ds && labels > 1U)
+			dns_name_getlabelsequence(secroot, 1, labels - 1,
+						  secroot);
 		result = dns_keytable_finddeepestmatch(val->keytable,
 						       secroot, secroot);
-
 		if (result == ISC_R_NOTFOUND) {
-			validator_log(val, ISC_LOG_DEBUG(3),
-				      "not beneath secure root");
 			if (val->mustbesecure) {
 				validator_log(val, ISC_LOG_WARNING,
 					      "must be secure failure");
@@ -2800,7 +2911,8 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 			if (result != ISC_R_SUCCESS)
 				goto out;
 			return (DNS_R_WAIT);
-		}
+		} else if (result == DNS_R_BROKENCHAIN)
+			return (result);
 	}
 	validator_log(val, ISC_LOG_DEBUG(3), "insecurity proof failed");
 	return (DNS_R_NOTINSECURE); /* Couldn't complete insecurity proof */
@@ -3007,6 +3119,8 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
 	val->seensig = ISC_FALSE;
 	val->havedlvsep = ISC_FALSE;
 	val->depth = 0;
+	val->authcount = 0;
+	val->authfail = 0;
 	val->mustbesecure = dns_resolver_getmustbesecure(view->resolver, name);
 	dns_rdataset_init(&val->frdataset);
 	dns_rdataset_init(&val->fsigrdataset);

lib/dns/view.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008, 2010  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: view.c,v 1.126.18.16 2008/06/17 23:46:03 tbox Exp $ */
+/* $Id: view.c,v 1.126.18.18 2010/02/26 23:46:37 tbox Exp $ */
 
 /*! \file */
 
@@ -1194,10 +1194,11 @@ dns_view_dumpdbtostream(dns_view_t *view, FILE *fp) {
 
 	(void)fprintf(fp, ";\n; Cache dump of view '%s'\n;\n", view->name);
 	result = dns_master_dumptostream(view->mctx, view->cachedb, NULL,
-					  &dns_master_style_cache, fp);
+					 &dns_master_style_cache, fp);
 	if (result != ISC_R_SUCCESS)
 		return (result);
 	dns_adb_dump(view->adb, fp);
+	dns_resolver_printbadcache(view->resolver, fp);
 	return (ISC_R_SUCCESS);
 }
 
@@ -1218,6 +1219,8 @@ dns_view_flushcache(dns_view_t *view) {
 	dns_cache_attachdb(view->cache, &view->cachedb);
 	if (view->acache != NULL)
 		dns_acache_setdb(view->acache, view->cachedb);
+	if (view->resolver != NULL)
+		dns_resolver_flushbadcache(view->resolver, NULL);
 
 	dns_adb_flush(view->adb);
 	return (ISC_R_SUCCESS);
@@ -1232,6 +1235,8 @@ dns_view_flushname(dns_view_t *view, dns_name_t *name) {
 		dns_adb_flushname(view->adb, name);
 	if (view->cache == NULL)
 		return (ISC_R_SUCCESS);
+	if (view->resolver != NULL)
+		dns_resolver_flushbadcache(view->resolver, name);
 	return (dns_cache_flushname(view->cache, name));
 }
 

lib/dns/win32/libdns.def

@@ -440,6 +440,7 @@ dns_rdataset_clone
 dns_rdataset_count
 dns_rdataset_current
 dns_rdataset_disassociate
+dns_rdataset_expire
 dns_rdataset_first
 dns_rdataset_getadditional
 dns_rdataset_getnoqname
@@ -450,6 +451,7 @@ dns_rdataset_makequestion
 dns_rdataset_next
 dns_rdataset_putadditional
 dns_rdataset_setadditional
+dns_rdataset_settrust
 dns_rdataset_totext
 dns_rdataset_towire
 dns_rdataset_towiresorted
@@ -488,6 +490,7 @@ dns_requestmgr_detach
 dns_requestmgr_shutdown
 dns_requestmgr_whenshutdown
 dns_resolver_addalternate
+dns_resolver_addbadcache
 dns_resolver_algorithm_supported
 dns_resolver_attach
 dns_resolver_cancelfetch
@@ -500,13 +503,16 @@ dns_resolver_disable_algorithm
 dns_resolver_dispatchmgr
 dns_resolver_dispatchv4
 dns_resolver_dispatchv6
+dns_resolver_flushbadcache
 dns_resolver_freeze
+dns_resolver_getbadcache
 dns_resolver_getlamettl
 dns_resolver_getudpsize
 dns_resolver_getzeronosoattl
 dns_resolver_logfetch
 dns_resolver_nrunning
 dns_resolver_prime
+dns_resolver_printbadcache
 dns_resolver_reset_algorithms
 dns_resolver_resetmustbesecure
 dns_resolver_setclientsperquery

util/copyrights

@@ -1,10 +1,10 @@
 ./.cvsignore					X	1998,1999,2000,2001,2004
-./CHANGES					X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./COPYRIGHT					TXT	1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
+./CHANGES					X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./COPYRIGHT					TXT	1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
 ./FAQ						X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
 ./FAQ.xml					SGML	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
 ./Makefile.in					MAKE	1998,1999,2000,2001,2002,2004,2005,2006,2007,2009
-./README					X	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
+./README					X	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
 ./README.idnkit					X	2005,2009
 ./acconfig.h					C	1999,2000,2001,2002,2003,2004,2005,2008
 ./aclocal.m4					X	1999,2000,2001
@@ -136,7 +136,7 @@
 ./bin/named/named.html				HTML	DOCBOOK
 ./bin/named/notify.c				C	1999,2000,2001,2002,2003,2004,2005
 ./bin/named/query.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./bin/named/server.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
+./bin/named/server.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
 ./bin/named/sortlist.c				C	2000,2001,2004,2005,2006
 ./bin/named/tkeyconf.c				C	1999,2000,2001,2004,2005,2006
 ./bin/named/tsigconf.c				C	1999,2000,2001,2004,2005,2006
@@ -496,12 +496,12 @@
 ./bin/tests/system/dnssec/ns2/.cvsignore	X	2000,2001
 ./bin/tests/system/dnssec/ns2/dlv.db.in		ZONE	2004
 ./bin/tests/system/dnssec/ns2/dst.example.db.in	ZONE	2004
-./bin/tests/system/dnssec/ns2/example.db.in	ZONE	2000,2001,2002,2004
+./bin/tests/system/dnssec/ns2/example.db.in	ZONE	2000,2001,2002,2004,2009
 ./bin/tests/system/dnssec/ns2/insecure.secure.example.db	ZONE	2000,2001,2004
 ./bin/tests/system/dnssec/ns2/named.conf	CONF-C	2000,2001,2002,2004,2006
 ./bin/tests/system/dnssec/ns2/private.secure.example.db.in	ZONE	2000,2001,2004
 ./bin/tests/system/dnssec/ns2/rfc2335.example.db	X	2004
-./bin/tests/system/dnssec/ns2/sign.sh		SH	2000,2001,2002,2003,2004,2006
+./bin/tests/system/dnssec/ns2/sign.sh		SH	2000,2001,2002,2003,2004,2006,2009
 ./bin/tests/system/dnssec/ns3/.cvsignore	X	2000,2001
 ./bin/tests/system/dnssec/ns3/bogus.example.db.in	ZONE	2000,2001,2004
 ./bin/tests/system/dnssec/ns3/dynamic.example.db.in	ZONE	2002,2004
@@ -518,7 +518,7 @@
 ./bin/tests/system/dnssec/ns6/named.conf	CONF-C	2004,2006,2007
 ./bin/tests/system/dnssec/prereq.sh		SH	2000,2001,2002,2004,2006
 ./bin/tests/system/dnssec/setup.sh		SH	2000,2001,2004
-./bin/tests/system/dnssec/tests.sh		SH	2000,2001,2002,2004,2005,2006
+./bin/tests/system/dnssec/tests.sh		SH	2000,2001,2002,2004,2005,2006,2009
 ./bin/tests/system/forward/clean.sh		SH	2000,2001,2004
 ./bin/tests/system/forward/ns1/.cvsignore	X	2000,2001
 ./bin/tests/system/forward/ns1/example.db	X	2000,2001
@@ -631,18 +631,20 @@
 ./bin/tests/system/nsupdate/update_test.pl	PERL	2000,2001,2004
 ./bin/tests/system/pending/clean.sh		SH	2009
 ./bin/tests/system/pending/ns1/named.conf	CONF-C	2009
-./bin/tests/system/pending/ns1/root.db.in	ZONE	2009
-./bin/tests/system/pending/ns1/sign.sh		SH	2009
-./bin/tests/system/pending/ns2/example.db.in	ZONE	2009
-./bin/tests/system/pending/ns2/named.conf	CONF-C	2009
-./bin/tests/system/pending/ns2/sign.sh		SH	2009
+./bin/tests/system/pending/ns1/root.db.in	ZONE	2009,2010
+./bin/tests/system/pending/ns1/sign.sh		SH	2009,2010
+./bin/tests/system/pending/ns2/example.com.db.in	ZONE	2009
+./bin/tests/system/pending/ns2/example.db.in	ZONE	2009,2010
+./bin/tests/system/pending/ns2/forgery.db	ZONE	2010
+./bin/tests/system/pending/ns2/named.conf	CONF-C	2009,2010
+./bin/tests/system/pending/ns2/sign.sh		SH	2009,2010
 ./bin/tests/system/pending/ns3/hostile.db	ZONE	2009
 ./bin/tests/system/pending/ns3/mail.example.db	ZONE	2009
 ./bin/tests/system/pending/ns3/named.conf	CONF-C	2009
 ./bin/tests/system/pending/ns4/named.conf	CONF-C	2009
 ./bin/tests/system/pending/prereq.sh		SH	2009
 ./bin/tests/system/pending/setup.sh		SH	2009
-./bin/tests/system/pending/tests.sh		SH	2009
+./bin/tests/system/pending/tests.sh		SH	2009,2010
 ./bin/tests/system/relay/README			TXT.BRIEF	2000,2001,2004
 ./bin/tests/system/relay/clean.sh		SH	2000,2001,2004
 ./bin/tests/system/relay/ns1/.cvsignore		X	2000,2001
@@ -1209,34 +1211,34 @@
 ./doc/.cvsignore				X	2000,2001
 ./doc/Makefile.in				MAKE	2000,2001,2004,2005
 ./doc/arm/.cvsignore				X	2000,2001,2005
-./doc/arm/Bv9ARM-book.xml			SGML	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.ch01.html			X	2000,2001,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.ch02.html			X	2000,2001,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.ch03.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.ch04.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.ch05.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.ch06.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.ch07.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.ch08.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.ch09.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.ch10.html			X	2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.html				X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./doc/arm/Bv9ARM.pdf				X	2005,2006,2007,2008,2009
+./doc/arm/Bv9ARM-book.xml			SGML	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.ch01.html			X	2000,2001,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.ch02.html			X	2000,2001,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.ch03.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.ch04.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.ch05.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.ch06.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.ch07.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.ch08.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.ch09.html			X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.ch10.html			X	2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.html				X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./doc/arm/Bv9ARM.pdf				X	2005,2006,2007,2008,2009,2010
 ./doc/arm/Makefile.in				MAKE	2001,2002,2004,2005,2006,2007,2009
 ./doc/arm/README-SGML				TXT.BRIEF	2000,2001,2004
 ./doc/arm/isc-logo.eps				X	2005
 ./doc/arm/isc-logo.pdf				X	2005
 ./doc/arm/latex-fixup.pl			PERL	2005
-./doc/arm/man.dig.html				X	2005,2006,2007,2008,2009
-./doc/arm/man.dnssec-keygen.html		X	2005,2006,2007,2008,2009
-./doc/arm/man.dnssec-signzone.html		X	2005,2006,2007,2008,2009
-./doc/arm/man.host.html				X	2005,2006,2007,2008,2009
-./doc/arm/man.named-checkconf.html		X	2005,2006,2007,2008,2009
-./doc/arm/man.named-checkzone.html		X	2005,2006,2007,2008,2009
-./doc/arm/man.named.html			X	2005,2006,2007,2008,2009
-./doc/arm/man.rndc-confgen.html			X	2005,2006,2007,2008,2009
-./doc/arm/man.rndc.conf.html			X	2005,2006,2007,2008,2009
-./doc/arm/man.rndc.html				X	2005,2006,2007,2008,2009
+./doc/arm/man.dig.html				X	2005,2006,2007,2008,2009,2010
+./doc/arm/man.dnssec-keygen.html		X	2005,2006,2007,2008,2009,2010
+./doc/arm/man.dnssec-signzone.html		X	2005,2006,2007,2008,2009,2010
+./doc/arm/man.host.html				X	2005,2006,2007,2008,2009,2010
+./doc/arm/man.named-checkconf.html		X	2005,2006,2007,2008,2009,2010
+./doc/arm/man.named-checkzone.html		X	2005,2006,2007,2008,2009,2010
+./doc/arm/man.named.html			X	2005,2006,2007,2008,2009,2010
+./doc/arm/man.rndc-confgen.html			X	2005,2006,2007,2008,2009,2010
+./doc/arm/man.rndc.conf.html			X	2005,2006,2007,2008,2009,2010
+./doc/arm/man.rndc.html				X	2005,2006,2007,2008,2009,2010
 ./doc/design/addressdb				TXT.BRIEF	2000,2001,2004
 ./doc/design/compression			TXT.BRIEF	1999,2000,2001,2004
 ./doc/design/database				TXT.BRIEF	1999,2000,2001,2004
@@ -1277,7 +1279,7 @@
 ./doc/misc/sdb					TXT.BRIEF	2000,2001,2004
 ./doc/misc/sort-options.pl			PERL	2007
 ./doc/private/CHANGES				X	2000,2001
-./doc/private/SRCID				X	2009
+./doc/private/SRCID				X	2009,2010
 ./doc/private/branches				X	2002,2003,2004
 ./doc/private/bugfix-by-assertion		X	2001
 ./doc/private/options				TXT.BRIEF	2000,2001,2004
@@ -1830,13 +1832,13 @@
 ./lib/dns/include/dns/rdata.h			C	1998,1999,2000,2001,2002,2003,2004,2005,2008,2009
 ./lib/dns/include/dns/rdataclass.h		C	1998,1999,2000,2001,2004,2005
 ./lib/dns/include/dns/rdatalist.h		C	1999,2000,2001,2004,2005
-./lib/dns/include/dns/rdataset.h		C	1999,2000,2001,2002,2003,2004,2005,2006,2009
+./lib/dns/include/dns/rdataset.h		C	1999,2000,2001,2002,2003,2004,2005,2006,2009,2010
 ./lib/dns/include/dns/rdatasetiter.h		C	1999,2000,2001,2004,2005
 ./lib/dns/include/dns/rdataslab.h		C	1999,2000,2001,2002,2004,2005
 ./lib/dns/include/dns/rdatatype.h		C	1998,1999,2000,2001,2004,2005
 ./lib/dns/include/dns/request.h			C	2000,2001,2002,2004,2005,2009
-./lib/dns/include/dns/resolver.h		C	1999,2000,2001,2003,2004,2005,2006,2009
-./lib/dns/include/dns/result.h			C	1998,1999,2000,2001,2002,2003,2004,2005
+./lib/dns/include/dns/resolver.h		C	1999,2000,2001,2003,2004,2005,2006,2009,2010
+./lib/dns/include/dns/result.h			C	1998,1999,2000,2001,2002,2003,2004,2005,2010
 ./lib/dns/include/dns/rootns.h			C	1999,2000,2001,2004,2005
 ./lib/dns/include/dns/sdb.h			C	2000,2001,2004,2005,2009
 ./lib/dns/include/dns/sdlz.h			C.PORTION	1999,2000,2001,2005,2009
@@ -1852,7 +1854,7 @@
 ./lib/dns/include/dns/tsig.h			C	1999,2000,2001,2002,2004,2005,2006
 ./lib/dns/include/dns/ttl.h			C	1999,2000,2001,2004,2005
 ./lib/dns/include/dns/types.h			C	1998,1999,2000,2001,2002,2003,2004,2005,2006,2009
-./lib/dns/include/dns/validator.h		C	2000,2001,2002,2003,2004,2005,2007,2009
+./lib/dns/include/dns/validator.h		C	2000,2001,2002,2003,2004,2005,2007,2009,2010
 ./lib/dns/include/dns/version.h			C	2001,2004,2005
 ./lib/dns/include/dns/view.h			C	1999,2000,2001,2002,2003,2004,2005,2006,2009
 ./lib/dns/include/dns/xfrin.h			C	1999,2000,2001,2003,2004,2005,2006,2009
@@ -1875,7 +1877,7 @@
 ./lib/dns/masterdump.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2008,2009
 ./lib/dns/message.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
 ./lib/dns/name.c				C	1998,1999,2000,2001,2002,2003,2004,2005,2006
-./lib/dns/ncache.c				C	1999,2000,2001,2002,2003,2004,2005
+./lib/dns/ncache.c				C	1999,2000,2001,2002,2003,2004,2005,2010
 ./lib/dns/nsec.c				C	1999,2000,2001,2003,2004,2005,2009
 ./lib/dns/openssl_link.c			C.NAI	1999,2000,2001,2002,2003,2004,2005,2006,2007,2009
 ./lib/dns/openssldh_link.c			C.NAI	1999,2000,2001,2002,2004,2005,2006,2007
@@ -1885,7 +1887,7 @@
 ./lib/dns/peer.c				C	2000,2001,2003,2004,2005,2006
 ./lib/dns/portlist.c				C	2003,2004,2005,2006
 ./lib/dns/rbt.c					C	1999,2000,2001,2002,2003,2004,2005,2008,2009
-./lib/dns/rbtdb.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
+./lib/dns/rbtdb.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
 ./lib/dns/rbtdb.h				C	1999,2000,2001,2004,2005
 ./lib/dns/rbtdb64.c				C	1999,2000,2001,2004,2005
 ./lib/dns/rbtdb64.h				C	1999,2000,2001,2004,2005
@@ -1997,17 +1999,17 @@
 ./lib/dns/rdata/in_1/wks_11.h			C	1999,2000,2001,2004
 ./lib/dns/rdata/rdatastructpre.h		C	1999,2000,2001,2004
 ./lib/dns/rdata/rdatastructsuf.h		C	1999,2000,2001,2004
-./lib/dns/rdatalist.c				C	1999,2000,2001,2003,2004,2005
+./lib/dns/rdatalist.c				C	1999,2000,2001,2003,2004,2005,2010
 ./lib/dns/rdatalist_p.h				C	2000,2001,2004,2005
-./lib/dns/rdataset.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2009
+./lib/dns/rdataset.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2009,2010
 ./lib/dns/rdatasetiter.c			C	1999,2000,2001,2004,2005
-./lib/dns/rdataslab.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2009
+./lib/dns/rdataslab.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2009,2010
 ./lib/dns/request.c				C	2000,2001,2002,2004,2005,2006,2008,2009
-./lib/dns/resolver.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./lib/dns/result.c				C	1998,1999,2000,2001,2002,2003,2004,2005
+./lib/dns/resolver.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./lib/dns/result.c				C	1998,1999,2000,2001,2002,2003,2004,2005,2010
 ./lib/dns/rootns.c				C	1999,2000,2001,2002,2004,2005,2007,2008
-./lib/dns/sdb.c					C	2000,2001,2003,2004,2005,2006,2007,2008,2009
-./lib/dns/sdlz.c				C.PORTION	1999,2000,2001,2005,2006,2007,2009
+./lib/dns/sdb.c					C	2000,2001,2003,2004,2005,2006,2007,2008,2009,2010
+./lib/dns/sdlz.c				C.PORTION	1999,2000,2001,2005,2006,2007,2009,2010
 ./lib/dns/soa.c					C	2000,2001,2004,2005
 ./lib/dns/ssu.c					C	2000,2001,2003,2004,2005,2006
 ./lib/dns/stats.c				C	2000,2001,2004,2005
@@ -2017,14 +2019,14 @@
 ./lib/dns/tkey.c				C	1999,2000,2001,2003,2004,2005,2008
 ./lib/dns/tsig.c				C	1999,2000,2001,2002,2004,2005,2006,2007,2008
 ./lib/dns/ttl.c					C	1999,2000,2001,2004,2005
-./lib/dns/validator.c				C	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
+./lib/dns/validator.c				C	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
 ./lib/dns/version.c				C	1998,1999,2000,2001,2004,2005
-./lib/dns/view.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008
+./lib/dns/view.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2010
 ./lib/dns/win32/DLLMain.c			C	2001,2004,2007
 ./lib/dns/win32/gen.dsp				X	2001
 ./lib/dns/win32/gen.dsw				X	2001
 ./lib/dns/win32/gen.mak				X	2001,2006
-./lib/dns/win32/libdns.def			X	2001,2002,2003,2004,2005,2006,2007,2008,2009
+./lib/dns/win32/libdns.def			X	2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
 ./lib/dns/win32/libdns.dsp			X	2001,2002,2003,2004,2005,2006
 ./lib/dns/win32/libdns.dsw			X	2001
 ./lib/dns/win32/libdns.mak			X	2001,2002,2003,2004,2005,2006
@@ -2562,7 +2564,7 @@
 ./util/check-instincludes.sh			SH	2000,2001,2004
 ./util/check-pullups.pl				PERL	2001,2002,2003,2004
 ./util/check-sources.pl				PERL	2000,2001,2004
-./util/copyrights				X	1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
+./util/copyrights				X	1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
 ./util/kit.sh					SH	2000,2001,2002,2003,2004,2005,2009
 ./util/mandoc2docbook.pl			PERL	2001,2004
 ./util/mdnbuildtest.sh				SH	2000,2001,2004
@@ -2575,7 +2577,7 @@
 ./util/tabify-changes				SH	2004
 ./util/update-drafts.pl				PERL	2000,2001,2004
 ./util/update_copyrights			PERL	1998,1999,2000,2001,2004,2005,2006,2007,2008,2009
-./version					X	1998,1999,2000,2001,2002,2003,2005,2006,2007,2008,2009
+./version					X	1998,1999,2000,2001,2002,2003,2005,2006,2007,2008,2009,2010
 ./win32utils/BINDBuild.dsw			X	2001,2005,2006
 ./win32utils/BuildAll.bat			BAT	2001,2002,2004,2005,2006,2007
 ./win32utils/BuildOpenSSL.bat			BAT	2007

version

@@ -1,4 +1,4 @@
-# $Id: version,v 1.29.134.27 2009/12/11 00:39:13 marka Exp $
+# $Id: version,v 1.29.134.30 2010/05/10 01:56:40 marka Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
@@ -7,4 +7,4 @@ MAJORVER=9
 MINORVER=4
 PATCHVER=
 RELEASETYPE=-ESV
-RELEASEVER=rc1
+RELEASEVER=-R2