omitted some test files

3121.   [security]      An authoritative name server sending a negative
                        response containing a very large RRset could
                        trigger an off-by-one error in the ncache code
                        and crash named. [RT #24650]

3120.	[bug]		Named could fail to validate zones listed in a DLV
			that validated insecure without using DLV and had
			DS records in the parent zone. [RT #24631]

CHANGES

@@ -1,3 +1,70 @@
+	--- 9.4-ESV-R4-P1 released ---
+
+3121.   [security]      An authoritative name server sending a negative
+                        response containing a very large RRset could
+                        trigger an off-by-one error in the ncache code
+                        and crash named. [RT #24650]
+
+3120.	[bug]		Named could fail to validate zones listed in a DLV
+			that validated insecure without using DLV and had
+			DS records in the parent zone. [RT #24631]
+
+	--- 9.4-ESV-R4 released ---
+
+2970.	[security]	Adding a NO DATA negative cache entry failed to clear
+			any matching RRSIG records.  A subsequent lookup of
+			of NO DATA cache entry could trigger a INSIST when the
+			unexpected RRSIG was also returned with the NO DATA
+			cache entry.
+
+			CVE-2010-3613, VU#706148. [RT #22288]
+
+2968.	[security]	Named could fail to prove a data set was insecure
+			before marking it as insecure.  One set of conditions
+			that can trigger this occurs naturally when rolling
+			DNSKEY algorithms.
+
+			CVE-2010-3614, VU#837744. [RT #22309]
+
+2966.	[bug]		isc_print_vsnprintf() failed to check if there was
+			space available in the buffer when adding a left
+			justified character with a non zero width,
+			(e.g. "%-1c"). [RT #22270]
+
+2962.	[port]		win32: add more dependancies to BINDBuild.dsw.
+			[RT #22062]
+
+2786.	[bug]		Additional could be promoted to answer. [RT #20663]
+
+	--- 9.4-ESV-R3 released ---
+
+2925.	[bug]		Named failed to accept uncachable negative responses
+			from insecure zones. [RT# 21555]
+
+2921.	[bug]		The resolver could attempt to destroy a fetch context
+			too soon.  [RT #19878]
+
+2904.   [bug]           When using DLV, sub-zones of the zones in the DLV,
+			could be incorrectly marked as insecure instead of
+			secure leading to negative proofs failing.  This was
+			a unintended outcome from change 2890. [RT# 21392]
+
+2900.	[bug]	 	The placeholder negative caching element was not
+			properly constructed triggering a INSIST in 
+			dns_ncache_towire(). [RT #21346]
+
+2890.	[bug]		Handle the introduction of new trusted-keys and
+			DS, DLV RRsets better. [RT #21097]
+
+2869.	[bug]		Fix arguments to dns_keytable_findnextkeynode() call.
+			[RT #20877]
+
+2678.	[func]		Treat DS queries as if "minimal-response yes;"
+			was set. [RT #20258]
+
+2427.	[func]		Treat DNSKEY queries as if "minimal-response yes;"
+			was set. [RT #18528]
+
 	--- 9.4-ESV-R2 released ---
 
 2876.	[bug]		Named could return SERVFAIL for negative responses

bin/named/query.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: query.c,v 1.257.18.53 2009/12/30 08:55:48 jinmei Exp $ */
+/* $Id: query.c,v 1.257.18.56 2010/11/17 10:21:01 marka Exp $ */
 
 /*! \file */
 
@@ -1129,7 +1129,8 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 			goto cleanup;
 	}
 	result = dns_db_find(db, name, version, type,
-			     client->query.dboptions | DNS_DBFIND_GLUEOK,
+			     client->query.dboptions |
+			     DNS_DBFIND_GLUEOK | DNS_DBFIND_ADDITIONALOK,
 			     client->now, &node, fname, rdataset,
 			     sigrdataset);
 	if (result == DNS_R_GLUE &&
@@ -1614,7 +1615,8 @@ query_addadditional2(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 		goto try_glue;
 
 	result = dns_db_find(db, name, version, type,
-			     client->query.dboptions | DNS_DBFIND_GLUEOK,
+			     client->query.dboptions |
+			     DNS_DBFIND_GLUEOK | DNS_DBFIND_ADDITIONALOK,
 			     client->now, &node, fname, NULL, NULL);
 	if (result == ISC_R_SUCCESS)
 		goto found;
@@ -4653,6 +4655,13 @@ ns_query_start(ns_client_t *client) {
 		}
 	}
 
+	/*
+	 * Turn on minimal response for DNSKEY and DS queries.
+	 */
+	if (qtype == dns_rdatatype_dnskey || qtype == dns_rdatatype_ds)
+		client->query.attributes |= (NS_QUERYATTR_NOAUTHORITY |
+					     NS_QUERYATTR_NOADDITIONAL);
+
 	/*
 	 * If the client has requested that DNSSEC checking be disabled,
 	 * allow lookups to return pending data and instruct the resolver

bin/tests/system/conf.sh.in

@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (C) 2004-2006, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2006, 2008-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 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: conf.sh.in,v 1.27.18.12 2009/11/25 23:46:51 tbox Exp $
+# $Id: conf.sh.in,v 1.27.18.14 2010/06/04 23:46:02 tbox Exp $
 
 #
 # Common configuration data for system tests, to be sourced into
@@ -43,9 +43,10 @@ CHECKCONF=$TOP/bin/check/named-checkconf
 # The "stress" test is not run by default since it creates enough
 # load on the machine to make it unusable to other users.
 # v6synth
-SUBDIRS="acl cacheclean checkconf checknames dnssec forward glue ixfr limits
-    lwresd masterfile masterformat notify nsupdate pending resolver rrsetorder
-    sortlist stub tkey unknown upforwd views xfer xferquota zonechecks"
+SUBDIRS="acl cacheclean checkconf checknames dlv dnssec forward glue ixfr
+    limits lwresd masterfile masterformat notify nsupdate pending
+    resolver rrsetorder sortlist stub tkey unknown upforwd views
+    xfer xferquota zonechecks"
 
 # PERL will be an empty string if no perl interpreter was found.
 PERL=@PERL@

bin/tests/system/dlv/clean.sh

@@ -1,8 +1,8 @@
 #!/bin/sh
 #
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2010  Internet Systems Consortium, Inc. ("ISC")
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
 # copyright notice and this permission notice appear in all copies.
 #
@@ -14,14 +14,35 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: clean.sh,v 1.2 2004/05/14 04:58:18 marka Exp $
+# $Id: clean.sh,v 1.2.2.3.10.1 2011/05/26 23:56:25 each Exp $
 
 rm -f random.data
 rm -f ns*/named.run
+rm -f ns1/K*
+rm -f ns1/dsset-*
+rm -f ns1/*.signed
+rm -f ns1/signer.err
+rm -f ns1/root.db
+rm -f ns2/K*
+rm -f ns2/dlvset-*
+rm -f ns2/dsset-*
+rm -f ns2/*.signed
+rm -f ns2/*.pre
+rm -f ns2/signer.err
+rm -f ns2/druz.db
 rm -f ns3/K*
 rm -f ns3/*.db
 rm -f ns3/*.signed
 rm -f ns3/dlvset-*
 rm -f ns3/dsset-*
 rm -f ns3/keyset-*
-rm -f ns3/trusted.conf ns5/trusted.conf
+rm -f ns1/trusted.conf ns5/trusted.conf
+rm -f ns3/trusted-dlv.conf ns5/trusted-dlv.conf
+rm -f ns3/signer.err
+rm -f ns6/K*
+rm -f ns6/*.db
+rm -f ns6/*.signed
+rm -f ns6/dsset-*
+rm -f ns6/signer.err
+rm -f */named.memstats
+rm -f dig.out.ns*.test*

bin/tests/system/dlv/ns1/named.conf

@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: named.conf,v 1.2 2004/05/14 04:58:20 marka Exp $ */
+/* $Id: named.conf,v 1.2.2.1.82.1 2011/05/26 23:56:26 each Exp $ */
 
 controls { /* empty */ };
 
@@ -28,8 +28,8 @@ options {
 	listen-on-v6 { none; };
 	recursion no;
 	notify yes;
-	dnssec-enable no;
+	dnssec-enable yes;
 };
 
-zone "." { type master; file "root.db"; };
+zone "." { type master; file "root.signed"; };
 zone "rootservers.utld" { type master; file "rootservers.utld.db"; };

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

@@ -1,6 +1,6 @@
-; Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+; Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 ;
-; Permission to use, copy, modify, and distribute this software for any
+; Permission to use, copy, modify, and/or distribute this software for any
 ; purpose with or without fee is hereby granted, provided that the above
 ; copyright notice and this permission notice appear in all copies.
 ;
@@ -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,v 1.2 2004/05/14 04:58:20 marka Exp $
+; $Id: root.db.in,v 1.3.12.2 2011/05/27 04:03:45 each Exp $
 
 $TTL	120
 @		SOA	ns.rootservers.utld hostmaster.ns.rootservers.utld (
@@ -22,3 +22,5 @@ ns		A	10.53.0.1
 ;
 utld		NS	ns.utld
 ns.utld		A	10.53.0.2
+druz		NS	ns.druz
+ns.druz		A	10.53.0.2

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

@@ -0,0 +1,52 @@
+#!/bin/sh
+#
+# Copyright (C) 2004, 2007, 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
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES 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: sign.sh,v 1.3.12.2 2011/05/27 04:03:45 each Exp $
+
+(cd ../ns2 && sh -e ./sign.sh || exit 1)
+
+echo "I:dlv/ns1/sign.sh"
+
+SYSTEMTESTTOP=../..
+. $SYSTEMTESTTOP/conf.sh
+
+RANDFILE=../random.data
+
+zone=.
+infile=root.db.in
+zonefile=root.db
+outfile=root.signed
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null` 
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -r $RANDFILE -g -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+
+echo "I: signed $zone"
+
+grep -v '^;' $keyname2.key | $PERL -n -e '
+local ($dn, $class, $type, $flags, $proto, $alg, @rest) = split;
+local $key = join("", @rest);
+print <<EOF
+trusted-keys {
+    "$dn" $flags $proto $alg "$key";
+};
+EOF
+' > trusted.conf
+cp trusted.conf ../ns5
+

bin/tests/system/dlv/ns2/druz.db.in

@@ -0,0 +1,54 @@
+; Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
+;
+; Permission to use, copy, modify, and/or distribute this software for any
+; purpose with or without fee is hereby granted, provided that the above
+; copyright notice and this permission notice appear in all copies.
+;
+; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+; AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+; PERFORMANCE OF THIS SOFTWARE.
+
+; $Id: druz.db.in,v 1.4.12.2 2011/05/27 04:03:46 each Exp $
+
+$TTL	120
+@		SOA	ns hostmaster.ns 1 3600 1200 604800 60
+@		NS	ns
+ns		A	10.53.0.2
+;
+rootservers	NS	ns.rootservers
+ns.rootservers	A	10.53.0.1
+;
+;
+child1		NS	ns.child1
+ns.child1	A	10.53.0.3
+;
+child2		NS	ns.child2
+ns.child2	A	10.53.0.4
+;
+child3		NS	ns.child3
+ns.child3	A	10.53.0.3
+;
+child4		NS	ns.child4
+ns.child4	A	10.53.0.3
+;
+child5		NS	ns.child5
+ns.child5	A	10.53.0.3
+;
+child6		NS	ns.child6
+ns.child6	A	10.53.0.4
+;
+child7		NS	ns.child7
+ns.child7	A	10.53.0.3
+;
+child8		NS	ns.child8
+ns.child8	A	10.53.0.3
+;
+child9		NS	ns.child9
+ns.child9	A	10.53.0.3
+;
+child10		NS	ns.child10
+ns.child10	A	10.53.0.3

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

@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: named.conf,v 1.2 2004/05/14 04:58:21 marka Exp $ */
+/* $Id: named.conf,v 1.2.2.1.82.1 2011/05/26 23:56:26 each Exp $ */
 
 controls { /* empty */ };
 
@@ -28,8 +28,9 @@ options {
 	listen-on-v6 { none; };
 	recursion no;
 	notify yes;
-	dnssec-enable no;
+	dnssec-enable yes;
 };
 
 zone "." { type hint; file "hints"; };
 zone "utld" { type master; file "utld.db"; };
+zone "druz" { type master; file "druz.signed"; };

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

@@ -0,0 +1,44 @@
+#!/bin/sh
+#
+# Copyright (C) 2004, 2007, 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
+# copyright notice and this permission notice appear in all copies.
+#
+# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES 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: sign.sh,v 1.3.12.2 2011/05/27 04:03:46 each Exp $
+
+(cd ../ns3 && sh -e ./sign.sh || exit 1)
+
+echo "I:dlv/ns2/sign.sh"
+
+SYSTEMTESTTOP=../..
+. $SYSTEMTESTTOP/conf.sh
+
+RANDFILE=../random.data
+
+zone=druz.
+infile=druz.db.in
+zonefile=druz.db
+outfile=druz.pre
+dlvzone=utld.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null` 
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -r $RANDFILE -l $dlvzone -g -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+
+$CHECKZONE -q -D -i none druz druz.pre |
+sed '/IN DNSKEY/s/\([a-z0-9A-Z/]\{10\}\)[a-z0-9A-Z/]\{16\}/\1XXXXXXXXXXXXXXXX/'> druz.signed
+
+echo "I: signed $zone"

bin/tests/system/dlv/ns3/child.db.in

@@ -1,6 +1,6 @@
-; Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+; Copyright (C) 2004, 2010  Internet Systems Consortium, Inc. ("ISC")
 ;
-; Permission to use, copy, modify, and distribute this software for any
+; Permission to use, copy, modify, and/or distribute this software for any
 ; purpose with or without fee is hereby granted, provided that the above
 ; copyright notice and this permission notice appear in all copies.
 ;
@@ -12,7 +12,7 @@
 ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 ; PERFORMANCE OF THIS SOFTWARE.
 
-; $Id: child.db.in,v 1.2 2004/05/14 04:58:21 marka Exp $
+; $Id: child.db.in,v 1.2.2.3 2010/06/04 23:46:02 tbox Exp $
 
 $TTL	120
 @		SOA	ns hostmaster.ns 1 3600 1200 604800 60
@@ -20,3 +20,5 @@ $TTL	120
 ns		A	10.53.0.3
 foo		TXT	foo
 bar		TXT	bar
+grand		NS	ns.grand
+ns.grand	A	10.53.0.6

bin/tests/system/dlv/ns3/named.conf

@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: named.conf,v 1.2 2004/05/14 04:58:22 marka Exp $ */
+/* $Id: named.conf,v 1.2.2.1.82.1 2011/05/26 23:56:26 each Exp $ */
 
 controls { /* empty */ };
 
@@ -41,3 +41,11 @@ zone "child7.utld" { type master; file "child7.signed"; };	// no dlv
 zone "child8.utld" { type master; file "child8.signed"; };	// no dlv
 zone "child9.utld" { type master; file "child9.signed"; };	// dlv
 zone "child10.utld" { type master; file "child.db.in"; }; 	// dlv unsigned
+zone "child1.druz" { type master; file "child1.druz.signed"; };	// dlv
+zone "child3.druz" { type master; file "child3.druz.signed"; };	// dlv
+zone "child4.druz" { type master; file "child4.druz.signed"; };	// dlv
+zone "child5.druz" { type master; file "child5.druz.signed"; };	// dlv
+zone "child7.druz" { type master; file "child7.druz.signed"; };	// no dlv
+zone "child8.druz" { type master; file "child8.druz.signed"; };	// no dlv
+zone "child9.druz" { type master; file "child9.druz.signed"; };	// dlv
+zone "child10.druz" { type master; file "child.db.in"; }; 	// dlv unsigned

bin/tests/system/dlv/ns3/sign.sh

@@ -1,8 +1,8 @@
 #!/bin/sh
 #
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2010  Internet Systems Consortium, Inc. ("ISC")
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
 # copyright notice and this permission notice appear in all copies.
 #
@@ -14,27 +14,32 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: sign.sh,v 1.2 2004/05/14 04:58:22 marka Exp $
+# $Id: sign.sh,v 1.2.2.3.10.1 2011/05/26 23:56:26 each Exp $
+
+(cd ../ns6 && sh -e sign.sh)
+
+echo "I:dlv/ns3/sign.sh"
 
 SYSTEMTESTTOP=../..
 . $SYSTEMTESTTOP/conf.sh
 
 RANDFILE=../random.data
+dlvzone=dlv.utld.
 dlvsets=
+dssets=
 
 zone=child1.utld.
 infile=child.db.in
 zonefile=child1.utld.db
 outfile=child1.signed
-dlvzone=dlv.utld.
 dlvsets="$dlvsets dlvset-$zone"
 
-keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone`
-keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone`
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null` 
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
 
-cat $infile $keyname1.key $keyname2.key >$zonefile
+cat $infile $keyname1.key $keyname2.key ../ns6/dsset-grand.$zone >$zonefile
 
-$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
 echo "I: signed $zone"
 
 
@@ -42,15 +47,14 @@ zone=child3.utld.
 infile=child.db.in
 zonefile=child3.utld.db
 outfile=child3.signed
-dlvzone=dlv.utld.
 dlvsets="$dlvsets dlvset-$zone"
 
-keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone`
-keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone`
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
 
-cat $infile $keyname1.key $keyname2.key >$zonefile
+cat $infile $keyname1.key $keyname2.key ../ns6/dsset-grand.$zone >$zonefile
 
-$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
 echo "I: signed $zone"
 
 
@@ -58,15 +62,14 @@ zone=child4.utld.
 infile=child.db.in
 zonefile=child4.utld.db
 outfile=child4.signed
-dlvzone=dlv.utld.
 dlvsets="$dlvsets dlvset-$zone"
 
-keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone`
-keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone`
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
 
 cat $infile $keyname1.key $keyname2.key >$zonefile
 
-$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
 echo "I: signed $zone"
 
 
@@ -74,15 +77,14 @@ zone=child5.utld.
 infile=child.db.in
 zonefile=child5.utld.db
 outfile=child5.signed
-dlvzone=dlv.utld.
 dlvsets="$dlvsets dlvset-$zone"
 
-keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone`
-keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone`
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
 
 cat $infile $keyname1.key $keyname2.key >$zonefile
 
-$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
 echo "I: signed $zone"
 
 
@@ -90,14 +92,13 @@ zone=child7.utld.
 infile=child.db.in
 zonefile=child7.utld.db
 outfile=child7.signed
-dlvzone=dlv.utld.
 
-keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone`
-keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone`
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
 
-cat $infile $keyname1.key $keyname2.key >$zonefile
+cat $infile $keyname1.key $keyname2.key ../ns6/dsset-grand.$zone >$zonefile
 
-$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null
+$SIGNER -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
 echo "I: signed $zone"
 
 
@@ -105,14 +106,13 @@ zone=child8.utld.
 infile=child.db.in
 zonefile=child8.utld.db
 outfile=child8.signed
-dlvzone=dlv.utld.
 
-keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone`
-keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone`
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
 
 cat $infile $keyname1.key $keyname2.key >$zonefile
 
-$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
 echo "I: signed $zone"
 
 
@@ -120,30 +120,150 @@ zone=child9.utld.
 infile=child.db.in
 zonefile=child9.utld.db
 outfile=child9.signed
-dlvzone=dlv.utld.
 dlvsets="$dlvsets dlvset-$zone"
 
-keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone`
-keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone`
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
 
 cat $infile $keyname1.key $keyname2.key >$zonefile
 
-$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.er
 echo "I: signed $zone"
 
 zone=child10.utld.
 infile=child.db.in
 zonefile=child10.utld.db
 outfile=child10.signed
-dlvzone=dlv.utld.
 dlvsets="$dlvsets dlvset-$zone"
 
-keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone`
-keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone`
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key ../ns6/dsset-grand.$zone >$zonefile
+
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+zone=child1.druz.
+infile=child.db.in
+zonefile=child1.druz.db
+outfile=child1.druz.signed
+dlvsets="$dlvsets dlvset-$zone"
+dssets="$dssets dsset-$zone"
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null` 
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key ../ns6/dsset-grand.$zone >$zonefile
+
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=child3.druz.
+infile=child.db.in
+zonefile=child3.druz.db
+outfile=child3.druz.signed
+dlvsets="$dlvsets dlvset-$zone"
+dssets="$dssets dsset-$zone"
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key ../ns6/dsset-grand.$zone >$zonefile
+
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=child4.druz.
+infile=child.db.in
+zonefile=child4.druz.db
+outfile=child4.druz.signed
+dlvsets="$dlvsets dlvset-$zone"
+dssets="$dssets dsset-$zone"
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
 
 cat $infile $keyname1.key $keyname2.key >$zonefile
 
-$SIGNER -g -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=child5.druz.
+infile=child.db.in
+zonefile=child5.druz.db
+outfile=child5.druz.signed
+dlvsets="$dlvsets dlvset-$zone"
+dssets="$dssets dsset-$zone"
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key ../ns6/dsset-grand.$zone >$zonefile
+
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=child7.druz.
+infile=child.db.in
+zonefile=child7.druz.db
+outfile=child7.druz.signed
+dssets="$dssets dsset-$zone"
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key ../ns6/dsset-grand.$zone >$zonefile
+
+$SIGNER -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=child8.druz.
+infile=child.db.in
+zonefile=child8.druz.db
+outfile=child8.druz.signed
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=child9.druz.
+infile=child.db.in
+zonefile=child9.druz.db
+outfile=child9.druz.signed
+dlvsets="$dlvsets dlvset-$zone"
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+zone=child10.druz.
+infile=child.db.in
+zonefile=child10.druz.db
+outfile=child10.druz.signed
+dlvsets="$dlvsets dlvset-$zone"
+dssets="$dssets dsset-$zone"
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -r $RANDFILE -l $dlvzone -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
 echo "I: signed $zone"
 
 
@@ -151,14 +271,13 @@ zone=dlv.utld.
 infile=dlv.db.in
 zonefile=dlv.utld.db
 outfile=dlv.signed
-dlvzone=dlv.utld.
 
-keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone`
-keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone`
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
 
 cat $infile $dlvsets $keyname1.key $keyname2.key >$zonefile
 
-$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null
+$SIGNER -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
 echo "I: signed $zone"
 
 
@@ -170,5 +289,7 @@ trusted-keys {
     "$dn" $flags $proto $alg "$key";
 };
 EOF
-' > trusted.conf
-cp trusted.conf ../ns5
+' > trusted-dlv.conf
+cp trusted-dlv.conf ../ns5
+
+cp $dssets ../ns2

bin/tests/system/dlv/ns5/named.conf

@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: named.conf,v 1.2.2.7 2007/08/28 07:20:02 tbox Exp $ */
+/* $Id: named.conf,v 1.2.2.7.42.1 2011/05/26 23:56:26 each Exp $ */
 
 /*
  * Choose a keyname that is unlikely to clash with any real key names.
@@ -46,6 +46,7 @@ controls {
 };
 
 include "trusted.conf";
+include "trusted-dlv.conf";
 
 options {
 	query-source address 10.53.0.5;

bin/tests/system/dlv/ns6/child.db.in

@@ -0,0 +1,22 @@
+; 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: child.db.in,v 1.2 2010/05/26 06:28:00 marka Exp $
+
+$TTL	120
+@		SOA	ns hostmaster.ns6 1 3600 1200 604800 60
+@		NS	ns
+ns		A	10.53.0.6
+foo		TXT	foo
+bar		TXT	bar

bin/tests/system/dlv/ns6/hints

@@ -0,0 +1,18 @@
+; 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: hints,v 1.3.12.2 2010/06/03 23:46:10 tbox Exp $
+
+. 0 NS ns.rootservers.utld.
+ns.rootservers.utld. 0 A 10.53.0.1

bin/tests/system/dlv/ns6/named.conf

@@ -0,0 +1,50 @@
+/*
+ * 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: named.conf,v 1.3.10.2.10.1 2011/05/26 23:56:26 each Exp $ */
+
+controls { /* empty */ };
+
+options {
+	query-source address 10.53.0.6;
+	notify-source 10.53.0.6;
+	transfer-source 10.53.0.6;
+	port 5300;
+	pid-file "named.pid";
+	listen-on { 10.53.0.6; };
+	listen-on-v6 { none; };
+	recursion no;
+	notify yes;
+	dnssec-enable yes;
+};
+
+zone "." { type hint; file "hints"; };
+zone "grand.child1.utld" { type master; file "grand.child1.signed"; };
+zone "grand.child3.utld" { type master; file "grand.child3.signed"; };
+zone "grand.child4.utld" { type master; file "grand.child4.signed"; };
+zone "grand.child5.utld" { type master; file "grand.child5.signed"; };
+zone "grand.child7.utld" { type master; file "grand.child7.signed"; };
+zone "grand.child8.utld" { type master; file "grand.child8.signed"; };
+zone "grand.child9.utld" { type master; file "grand.child9.signed"; };
+zone "grand.child10.utld" { type master; file "grand.child.db.in"; };
+zone "grand.child1.druz" { type master; file "grand.child1.druz.signed"; };
+zone "grand.child3.druz" { type master; file "grand.child3.druz.signed"; };
+zone "grand.child4.druz" { type master; file "grand.child4.druz.signed"; };
+zone "grand.child5.druz" { type master; file "grand.child5.druz.signed"; };
+zone "grand.child7.druz" { type master; file "grand.child7.druz.signed"; };
+zone "grand.child8.druz" { type master; file "grand.child8.druz.signed"; };
+zone "grand.child9.druz" { type master; file "grand.child9.druz.signed"; };
+zone "grand.child10.druz" { type master; file "grand.child10.druz.signed"; };

bin/tests/system/dlv/ns6/sign.sh

@@ -0,0 +1,258 @@
+#!/bin/sh
+#
+# 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: sign.sh,v 1.3.10.2.10.1 2011/05/26 23:56:26 each Exp $
+
+SYSTEMTESTTOP=../..
+. $SYSTEMTESTTOP/conf.sh
+
+echo "I:dlv/ns6/sign.sh"
+
+RANDFILE=../random.data
+
+zone=grand.child1.utld.
+infile=child.db.in
+zonefile=grand.child1.utld.db
+outfile=grand.child1.signed
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child3.utld.
+infile=child.db.in
+zonefile=grand.child3.utld.db
+outfile=grand.child3.signed
+dlvzone=dlv.utld.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child4.utld.
+infile=child.db.in
+zonefile=grand.child4.utld.db
+outfile=grand.child4.signed
+dlvzone=dlv.utld.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child5.utld.
+infile=child.db.in
+zonefile=grand.child5.utld.db
+outfile=grand.child5.signed
+dlvzone=dlv.utld.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child7.utld.
+infile=child.db.in
+zonefile=grand.child7.utld.db
+outfile=grand.child7.signed
+dlvzone=dlv.utld.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child8.utld.
+infile=child.db.in
+zonefile=grand.child8.utld.db
+outfile=grand.child8.signed
+dlvzone=dlv.utld.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child9.utld.
+infile=child.db.in
+zonefile=grand.child9.utld.db
+outfile=grand.child9.signed
+dlvzone=dlv.utld.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+zone=grand.child10.utld.
+infile=child.db.in
+zonefile=grand.child10.utld.db
+outfile=grand.child10.signed
+dlvzone=dlv.utld.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+zone=grand.child1.druz.
+infile=child.db.in
+zonefile=grand.child1.druz.db
+outfile=grand.child1.druz.signed
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child3.druz.
+infile=child.db.in
+zonefile=grand.child3.druz.db
+outfile=grand.child3.druz.signed
+dlvzone=dlv.druz.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child4.druz.
+infile=child.db.in
+zonefile=grand.child4.druz.db
+outfile=grand.child4.druz.signed
+dlvzone=dlv.druz.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child5.druz.
+infile=child.db.in
+zonefile=grand.child5.druz.db
+outfile=grand.child5.druz.signed
+dlvzone=dlv.druz.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child7.druz.
+infile=child.db.in
+zonefile=grand.child7.druz.db
+outfile=grand.child7.druz.signed
+dlvzone=dlv.druz.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child8.druz.
+infile=child.db.in
+zonefile=grand.child8.druz.db
+outfile=grand.child8.druz.signed
+dlvzone=dlv.druz.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+
+zone=grand.child9.druz.
+infile=child.db.in
+zonefile=grand.child9.druz.db
+outfile=grand.child9.druz.signed
+dlvzone=dlv.druz.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"
+
+zone=grand.child10.druz.
+infile=child.db.in
+zonefile=grand.child10.druz.db
+outfile=grand.child10.druz.signed
+dlvzone=dlv.druz.
+
+keyname1=`$KEYGEN -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+keyname2=`$KEYGEN -f KSK -r $RANDFILE -a DSA -b 768 -n zone $zone 2> /dev/null`
+
+cat $infile $keyname1.key $keyname2.key >$zonefile
+
+$SIGNER -g -r $RANDFILE -o $zone -f $outfile $zonefile > /dev/null 2> signer.err || cat signer.err
+echo "I: signed $zone"

bin/tests/system/dlv/setup.sh

@@ -14,8 +14,8 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: setup.sh,v 1.2 2004/05/14 04:58:19 marka Exp $
+# $Id: setup.sh,v 1.2.2.1.82.1 2011/05/26 23:56:26 each Exp $
 
 ../../genrandom 400 random.data
 
-(cd ns3 && sh -e sign.sh)
+(cd ns1 && sh -e sign.sh)

bin/tests/system/dlv/tests.sh

@@ -1,8 +1,8 @@
 #!/bin/sh
 #
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2010  Internet Systems Consortium, Inc. ("ISC")
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
 # copyright notice and this permission notice appear in all copies.
 #
@@ -14,6 +14,49 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: tests.sh,v 1.2 2004/05/14 04:58:19 marka Exp $
+# $Id: tests.sh,v 1.2.2.3.10.1 2011/05/26 23:56:26 each Exp $
 
-exit 0
+SYSTEMTESTTOP=..
+. $SYSTEMTESTTOP/conf.sh
+
+status=0
+n=0
+
+rm -f dig.out.*
+
+DIGOPTS="+tcp +noadd +nosea +nostat +nocmd +dnssec -p 5300"
+
+echo "I:checking that DNSKEY reference by DLV validates as secure ($n)"
+ret=0
+$DIG $DIGOPTS child1.utld dnskey @10.53.0.5 > dig.out.ns5.test$n || ret=1
+grep "flags:.*ad.*QUERY" dig.out.ns5.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 child DNSKEY reference by DLV validates as secure ($n)"
+ret=0
+$DIG $DIGOPTS grand.child1.utld dnskey @10.53.0.5 > dig.out.ns5.test$n || ret=1
+grep "flags:.*ad.*QUERY" dig.out.ns5.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 SOA reference by DLV in a DRUZ with DS validates as secure ($n)"
+ret=0
+$DIG $DIGOPTS child1.druz soa @10.53.0.5 > dig.out.ns5.test$n || ret=1
+grep "flags:.*ad.*QUERY" dig.out.ns5.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 child SOA reference by DLV in a DRUZ with DS validates as secure ($n)"
+ret=0
+$DIG $DIGOPTS grand.child1.druz soa @10.53.0.5 > dig.out.ns5.test$n || ret=1
+grep "flags:.*ad.*QUERY" dig.out.ns5.test$n > /dev/null || ret=1
+n=`expr $n + 1`
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
+echo "I:exit status: $status"
+exit $status

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

@@ -1,7 +1,7 @@
-; Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+; Copyright (C) 2004, 2010  Internet Systems Consortium, Inc. ("ISC")
 ; Copyright (C) 2000, 2001  Internet Software Consortium.
 ;
-; Permission to use, copy, modify, and distribute this software for any
+; Permission to use, copy, modify, and/or distribute this software for any
 ; purpose with or without fee is hereby granted, provided that the above
 ; copyright notice and this permission notice appear in all copies.
 ;
@@ -13,7 +13,7 @@
 ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 ; PERFORMANCE OF THIS SOFTWARE.
 
-; $Id: root.db.in,v 1.8 2004/03/10 02:19:53 marka Exp $
+; $Id: root.db.in,v 1.8.18.2 2010/11/16 23:45:23 tbox Exp $
 
 $TTL 300
 . 			IN SOA	gson.nominum.com. a.root.servers.nil. (
@@ -30,3 +30,5 @@ example.		NS	ns2.example.
 ns2.example.		A	10.53.0.2
 dlv.			NS	ns2.dlv.
 ns2.dlv.		A	10.53.0.2
+algroll			NS	ns2.algroll
+ns2.algroll.		A	10.53.0.2

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

@@ -1,9 +1,9 @@
 #!/bin/sh
 #
-# Copyright (C) 2004, 2006  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2006, 2010  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.19.18.2 2006/01/04 00:37:23 marka Exp $
+# $Id: sign.sh,v 1.19.18.4 2010/11/16 23:45:23 tbox Exp $
 
 SYSTEMTESTTOP=../..
 . $SYSTEMTESTTOP/conf.sh
@@ -28,15 +28,16 @@ zonefile=root.db
 
 (cd ../ns2 && sh sign.sh )
 
-cp ../ns2/keyset-example. .
-cp ../ns2/keyset-dlv. .
+cp ../ns2/dsset-example. .
+cp ../ns2/dsset-dlv. .
+grep "5 [12]" ../ns2/dsset-algroll. > dsset-algroll.
 
 keyname=`$KEYGEN -r $RANDFILE -a RSAMD5 -b 768 -n zone $zone`
 
-cat $infile $keyname.key > $zonefile
+cat $infile $keyname.key dsset-example. dsset-dlv. dsset-algroll. > $zonefile
 
-echo $SIGNER -g -r $RANDFILE -o $zone $zonefile
-$SIGNER -g -r $RANDFILE -o $zone $zonefile > /dev/null
+echo $SIGNER -r $RANDFILE -o $zone $zonefile
+$SIGNER -r $RANDFILE -o $zone $zonefile > /dev/null
 
 # Configure the resolving server with a trusted key.
 

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

@@ -0,0 +1,31 @@
+; 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: algroll.db.in,v 1.2.12.3 2010/11/16 23:45:23 tbox Exp $
+
+$TTL 30	; 5 minutes
+@			IN SOA	mname1. . (
+				2000042407 ; serial
+				20         ; refresh (20 seconds)
+				20         ; retry (20 seconds)
+				1814400    ; expire (3 weeks)
+				30       ; minimum (1 hour)
+				)
+			NS	ns2
+ns2			A	10.53.0.2
+ns3			A	10.53.0.3
+
+a			A	10.0.0.1
+b			A	10.0.0.2
+d			A	10.0.0.4

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

@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2006, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: named.conf,v 1.23.18.3 2006/03/10 00:23:20 marka Exp $ */
+/* $Id: named.conf,v 1.23.18.5 2010/11/16 23:45:23 tbox Exp $ */
 
 // NS2
 
@@ -69,4 +69,9 @@ zone "rfc2335.example" {
 };
 
 
+zone "algroll" {
+	type master;
+	file "algroll.db.signed";
+};
+
 include "trusted.conf";

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

@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (C) 2004, 2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2006, 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 @@
 # 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.4 2009/12/30 23:46:04 tbox Exp $
+# $Id: sign.sh,v 1.24.18.6 2010/11/16 23:45:23 tbox Exp $
 
 SYSTEMTESTTOP=../..
 . $SYSTEMTESTTOP/conf.sh
@@ -113,3 +113,21 @@ dlvkeyname=`$KEYGEN -r $RANDFILE -a RSAMD5 -b 768 -n zone $dlvzone`
 cat $dlvinfile $dlvkeyname.key dlvset-$privzone > $dlvzonefile
 
 $SIGNER -g -r $RANDFILE -o $dlvzone $dlvzonefile > /dev/null
+
+#
+# algroll has just has the old DNSKEY records removed and is waiting
+# for them to be flushed from caches.  We still need to generate
+# RRSIGs for the old DNSKEY.
+#
+zone=algroll.
+infile=algroll.db.in
+zonefile=algroll.db
+
+keyold1=`$KEYGEN -r $RANDFILE -a RSAMD5 -b 1024 -n zone -f KSK $zone`
+keyold2=`$KEYGEN -r $RANDFILE -a RSAMD5 -b 1024 -n zone $zone`
+keynew1=`$KEYGEN -r $RANDFILE -a RSASHA1 -b 1024 -n zone -f KSK $zone`
+keynew2=`$KEYGEN -r $RANDFILE -a RSASHA1 -b 1024 -n zone $zone`
+
+cat $infile $keynew1.key $keynew2.key >$zonefile
+
+$SIGNER -r $RANDFILE -o $zone -k $keyold1 -k $keynew1 $zonefile $keyold1 $keyold2 $keynew1 $keynew2 > /dev/null

bin/tests/system/dnssec/tests.sh

@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2006, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000-2002  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
 # 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.7 2009/12/30 23:46:03 tbox Exp $
+# $Id: tests.sh,v 1.44.18.9 2010/11/16 23:45:23 tbox Exp $
 
 SYSTEMTESTTOP=..
 . $SYSTEMTESTTOP/conf.sh
@@ -509,6 +509,14 @@ n=`expr $n + 1`
 if [ $ret != 0 ]; then echo "I:failed"; fi
 status=`expr $status + $ret`
 
+echo "I:checking that a zone finishing the transition from RSAMD5 to RSASHA1 validates secure ($n)"
+ret=0
+$DIG $DIGOPTS ns algroll. @10.53.0.4 > dig.out.ns4.test$n || ret=1
+grep "NOERROR" dig.out.ns4.test$n > /dev/null || ret=1
+grep "flags:[^;]* ad[^;]*;" dig.out.ns4.test$n > /dev/null || ret=1
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
 # Run a minimal update test if possible.  This is really just
 # a regression test for RT #2399; more tests should be added.
 

bin/tests/system/resolver/ans2/ans.pl

@@ -1,6 +1,6 @@
 #!/usr/bin/perl
 #
-# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007, 2010  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: ans.pl,v 1.7.18.2 2007/12/02 23:46:31 tbox Exp $
+# $Id: ans.pl,v 1.7.18.4 2010/06/04 23:46:02 tbox Exp $
 
 #
 # Ad hoc name server
@@ -61,6 +61,11 @@ for (;;) {
 		# Data for the "cname + other data / 2" test: same RRs in opposite order
 		$packet->push("answer", new Net::DNS::RR("cname2.example.com 300 A 1.2.3.4"));
 		$packet->push("answer", new Net::DNS::RR("cname2.example.com 300 CNAME cname2.example.com"));
+	} elsif ($qname =~ /^nodata\.example\.net$/i) {
+		$packet->header->aa(1);
+	} elsif ($qname =~ /^nxdomain\.example\.net$/i) {
+		$packet->header->aa(1);
+		$packet->header->rcode(NXDOMAIN)
 	} else {
 		# Data for the "bogus referrals" test
 		$packet->push("authority", new Net::DNS::RR("below.www.example.com 300 NS ns.below.www.example.com"));

bin/tests/system/resolver/clean.sh

@@ -0,0 +1,18 @@
+# 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: clean.sh,v 1.4.2.3 2010/11/16 23:45:23 tbox Exp $
+
+rm -f ns6/K*
+rm -f ns6/example.net.db.signed ns6/example.net.db

bin/tests/system/resolver/ns6/example.net.db.in

@@ -0,0 +1,22 @@
+; 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: example.net.db.in,v 1.2.12.3 2010/11/16 23:45:23 tbox Exp $
+
+$TTL 600
+@	IN SOA	ns hostmaster 1 1800 900 604800 600
+@	IN NS	ns
+@	IN MX	0 mail
+ns	IN A	10.53.0.6
+mail	IN A	10.53.0.6

bin/tests/system/resolver/ns6/keygen.sh

@@ -0,0 +1,31 @@
+#!/bin/sh -e
+#
+# 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: keygen.sh,v 1.2.12.3 2010/11/17 10:11:43 marka Exp $
+
+SYSTEMTESTTOP=../..
+. $SYSTEMTESTTOP/conf.sh
+
+RANDFILE=../random.data
+
+zone=example.net
+zonefile="${zone}.db"
+infile="${zonefile}.in"
+cp $infile $zonefile
+ksk=`$KEYGEN -a RSASHA1 -b 1024 -n zone -r $RANDFILE -f KSK $zone`
+zsk=`$KEYGEN -a RSASHA1 -b 1024 -n zone -r $RANDFILE $zone`
+cat $ksk.key $zsk.key >> $zonefile
+$SIGNER -r $RANDFILE -o $zone $zonefile > /dev/null 2>&1

bin/tests/system/resolver/ns6/named.conf

@@ -0,0 +1,44 @@
+/*
+ * 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: named.conf,v 1.2.12.2 2010/11/16 08:01:09 marka Exp $ */
+
+// NS4
+
+controls { /* empty */ };
+
+options {
+	query-source address 10.53.0.6;
+	notify-source 10.53.0.6;
+	transfer-source 10.53.0.6;
+	port 5300;
+	pid-file "named.pid";
+	listen-on { 10.53.0.6; };
+	listen-on-v6 { none; };
+	recursion no;
+	// minimal-responses yes;
+};
+
+zone "." {
+	type master;
+	file "root.db";
+};
+
+zone "example.net" {
+	type master;
+	file "example.net.db.signed";
+	allow-update { any; };
+};

bin/tests/system/resolver/ns6/root.db

@@ -0,0 +1,26 @@
+; 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: root.db,v 1.2.12.2 2010/11/16 08:01:09 marka Exp $
+
+$TTL 300
+. 			IN SOA	marka.isc.org. a.root.servers.nil. (
+				2010   	; serial
+				600         	; refresh
+				600         	; retry
+				1200    	; expire
+				600       	; minimum
+				)
+.			NS	a.root-servers.nil.
+a.root-servers.nil.	A	10.53.0.6

bin/tests/system/resolver/ns7/named.conf

@@ -0,0 +1,37 @@
+/*
+ * 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: named.conf,v 1.2.12.2 2010/11/16 08:01:09 marka Exp $ */
+
+// NS4
+
+controls { /* empty */ };
+
+options {
+	query-source address 10.53.0.7;
+	notify-source 10.53.0.7;
+	transfer-source 10.53.0.7;
+	port 5300;
+	pid-file "named.pid";
+	listen-on { 10.53.0.7; };
+	listen-on-v6 { none; };
+	recursion yes;
+};
+
+zone "." {
+	type hint;
+	file "root.hint";
+};

bin/tests/system/resolver/ns7/root.hint

@@ -0,0 +1,19 @@
+; 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: root.hint,v 1.2.12.2 2010/11/16 08:01:09 marka Exp $
+
+$TTL 999999
+.			 IN NS	a.root-servers.nil.
+a.root-servers.nil.	 IN A	10.53.0.6

bin/tests/system/resolver/setup.sh

@@ -0,0 +1,21 @@
+#!/bin/sh -e
+#
+# 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: setup.sh,v 1.2.12.4 2010/11/17 09:12:52 marka Exp $
+
+../../genrandom 400 random.data
+
+(cd ns6 && sh keygen.sh)

bin/tests/system/resolver/tests.sh

@@ -1,9 +1,9 @@
 #!/bin/sh
 #
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2010  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
 # copyright notice and this permission notice appear in all copies.
 #
@@ -15,13 +15,28 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: tests.sh,v 1.7 2004/03/05 05:02:27 marka Exp $
+# $Id: tests.sh,v 1.7.18.4 2010/11/17 10:10:55 marka Exp $
 
 SYSTEMTESTTOP=..
 . $SYSTEMTESTTOP/conf.sh
 
 status=0
+n=0
 
+echo "I:checking non-cachable NXDOMAIN response handling"
+ret=0
+$DIG +tcp nxdomain.example.net @10.53.0.1 a -p 5300 > dig.out || ret=1
+grep "status: NXDOMAIN" dig.out > /dev/null || ret=1
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
+
+echo "I:checking non-cachable NODATA response handling"
+ret=0
+$DIG +tcp nodata.example.net @10.53.0.1 a -p 5300 > dig.out || ret=1
+grep "status: NOERROR" dig.out > /dev/null || ret=1
+
+if [ $ret != 0 ]; then echo "I:failed"; fi
+status=`expr $status + $ret`
 echo "I:checking handling of bogus referrals"
 # If the server has the "INSIST(!external)" bug, this query will kill it.
 $DIG +tcp www.example.com. a @10.53.0.1 -p 5300 >/dev/null || status=1
@@ -35,5 +50,31 @@ $DIG +tcp cname2.example.com. a @10.53.0.1 -p 5300 >/dev/null || status=1
 echo "I:check that server is still running"
 $DIG +tcp www.example.com. a @10.53.0.1 -p 5300 >/dev/null || status=1
 
+
+n=`expr $n + 1`
+echo "I:check that replacement of additional data by a negative cache no data entry clears the additional RRSIGs ($n)"
+ret=0
+$DIG +tcp mx example.net @10.53.0.7 -p 5300 > dig.ns7.out.${n} || ret=1
+grep "status: NOERROR" dig.ns7.out.${n} > /dev/null || ret=1
+if [ $ret = 1 ]; then echo "I:mx priming failed"; fi
+$NSUPDATE << EOF
+server 10.53.0.6 5300
+zone example.net
+update delete mail.example.net A
+update add mail.example.net 0 AAAA ::1
+send
+EOF
+$DIG +tcp a mail.example.net @10.53.0.7 -p 5300 > dig.ns7.out.${n} || ret=2
+grep "status: NOERROR" dig.ns7.out.${n} > /dev/null || ret=2
+grep "ANSWER: 0" dig.ns7.out.${n} > /dev/null || ret=2
+if [ $ret = 2 ]; then echo "I:ncache priming failed"; fi
+$DIG +tcp mx example.net @10.53.0.7 -p 5300 > dig.ns7.out.${n} || ret=3
+grep "status: NOERROR" dig.ns7.out.${n} > /dev/null || ret=3
+$DIG +tcp rrsig mail.example.net +norec @10.53.0.7 -p 5300 > dig.ns7.out.${n}  || ret=4
+grep "status: NOERROR" dig.ns7.out.${n} > /dev/null || ret=4
+grep "ANSWER: 0" dig.ns7.out.${n} > /dev/null || ret=4
+if [ $ret != 0 ]; then echo "I:failed"; ret=1; fi
+status=`expr $status + $ret`
+
 echo "I:exit status: $status"
 exit $status

bin/tests/system/testsock.pl

@@ -1,9 +1,9 @@
 #!/usr/bin/perl
 #
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2010  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
 # copyright notice and this permission notice appear in all copies.
 #
@@ -15,7 +15,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: testsock.pl,v 1.14 2004/03/05 04:59:13 marka Exp $
+# $Id: testsock.pl,v 1.14.18.2 2010/08/17 23:45:18 tbox Exp $
 
 # Test whether the interfaces on 10.53.0.* are up.
 
@@ -33,7 +33,7 @@ my @ids;
 if ($id != 0) {
 	@ids = ($id);
 } else {
-	@ids = (1..5);
+	@ids = (1..6);
 }
 
 foreach $id (@ids) {

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

@@ -5,12 +5,12 @@ Network Working Group                                          S. Weiler
 Internet-Draft                                              SPARTA, Inc.
 Updates: 4033, 4034, 4035, 5155                                D. Blacka
 (if approved)                                             VeriSign, Inc.
-Intended status: Standards Track                           March 8, 2010
-Expires: September 9, 2010
+Intended status: Standards Track                       November 10, 2010
+Expires: May 14, 2011
 
 
          Clarifications and Implementation Notes for DNSSECbis
-                draft-ietf-dnsext-dnssec-bis-updates-10
+                draft-ietf-dnsext-dnssec-bis-updates-12
 
 Abstract
 
@@ -20,26 +20,20 @@ Abstract
 
 Status of this Memo
 
-   This Internet-Draft is submitted to IETF in full conformance with the
+   This Internet-Draft is submitted 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.
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    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 9, 2010.
+   This Internet-Draft will expire on May 14, 2011.
 
 Copyright Notice
 
@@ -49,20 +43,18 @@ Copyright Notice
    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
-
-
-
-Weiler & Blacka         Expires September 9, 2010               [Page 1]
-
-Internet-Draft       DNSSECbis Implementation Notes           March 2010
-
-
    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.
+   described in the Simplified BSD License.
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 1]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
 
 
 Table of Contents
@@ -72,45 +64,53 @@ Table of Contents
      1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Important Additions to DNSSSECbis  . . . . . . . . . . . . . .  3
      2.1.  NSEC3 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 . . . . . . . . . . .  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 . . . . . . . . . . .  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 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
+     2.2.  SHA-2 Support  . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Implement a BAD cache  . . . . . . . . . . . . . . . . . .  4
+   4.  Security Concerns  . . . . . . . . . . . . . . . . . . . . . .  4
+     4.1.  Clarifications on Non-Existence Proofs . . . . . . . . . .  4
+     4.2.  Validating Responses to an ANY Query . . . . . . . . . . .  5
+     4.3.  Check for CNAME  . . . . . . . . . . . . . . . . . . . . .  5
+     4.4.  Insecure Delegation Proofs . . . . . . . . . . . . . . . .  5
+   5.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
+     5.1.  Errors in Canonical Form Type Code List  . . . . . . . . .  6
+     5.2.  Unknown DS Message Digest Algorithms . . . . . . . . . . .  6
+     5.3.  Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
+     5.4.  Caution About Local Policy and Multiple RRSIGs . . . . . .  7
+     5.5.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
+     5.6.  Setting the DO Bit on Replies  . . . . . . . . . . . . . .  8
+     5.7.  Setting the AD Bit on Queries  . . . . . . . . . . . . . .  8
+     5.8.  Setting the AD Bit on Replies  . . . . . . . . . . . . . .  8
+     5.9.  Handling Queries With the CD Bit Set . . . . . . . . . . .  8
+     5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . .  9
+       5.10.1.  Closest Encloser  . . . . . . . . . . . . . . . . . .  9
+       5.10.2.  Accept Any Success  . . . . . . . . . . . . . . . . .  9
+       5.10.3.  Preference Based on Source  . . . . . . . . . . . . . 10
+   6.  Minor Corrections and Clarifications . . . . . . . . . . . . . 10
+     6.1.  Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . . 10
+     6.2.  Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 11
+     6.3.  Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
+     6.4.  Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
    Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 13
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
 
 
 
 
-Weiler & Blacka         Expires September 9, 2010               [Page 2]
+
+
+
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 2]
 
-Internet-Draft       DNSSECbis Implementation Notes           March 2010
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
 
 
 1.  Introduction and Terminology
@@ -158,37 +158,47 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    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
+   SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512)
+   signal that a zone MAY be using NSEC3, rather than NSEC.  The zone
+   MAY indeed be using either and validators supporting these algorithms
 
 
 
-Weiler & Blacka         Expires September 9, 2010               [Page 3]
+Weiler & Blacka           Expires May 14, 2011                  [Page 3]
 
-Internet-Draft       DNSSECbis Implementation Notes           March 2010
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
 
 
-   responses.
+   MUST support both NSEC3 and NSEC responses.
 
-2.2.  SHA-256 Support
+2.2.  SHA-2 Support
 
    [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.
+   RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
+   Validator implementations are strongly encouraged to include support
+   for these algorithms for DS, DNSKEY, and RRSIG records.
 
    Both [RFC4509] and [RFC5702] should also be considered part of the
    DNS Security Document Family as described by [RFC4033], Section 10.
 
 
-3.  Security Concerns
+3.  Scaling Concerns
+
+3.1.  Implement a BAD cache
+
+   Section 4.7 of RFC4035 permits security-aware resolvers to implement
+   a BAD cache.  Because of scaling concerns not discussed in this
+   document, that guidance has changed: security-aware resolvers SHOULD
+   implement a BAD cache, as described in RFC4035.
+
+
+4.  Security Concerns
 
    This section provides clarifications that, if overlooked, could lead
    to security issues.
 
-3.1.  Clarifications on Non-Existence Proofs
+4.1.  Clarifications on Non-Existence Proofs
 
    [RFC4035] Section 5.4 under-specifies the algorithm for checking non-
    existence proofs.  In particular, the algorithm as presented would
@@ -207,6 +217,14 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    that (original) owner name other than DS RRs, and all RRs below that
    owner name regardless of type.
 
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 4]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    Similarly, the algorithm would also allow an NSEC RR at the same
    owner name as a DNAME RR, or an NSEC3 RR at the same original owner
    name as a DNAME, to prove the non-existence of names beneath that
@@ -214,18 +232,7 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    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
+4.2.  Validating Responses to an ANY Query
 
    [RFC4035] does not address how to validate responses when QTYPE=*.
    As described in Section 6.2.2 of [RFC1034], a proper response to
@@ -241,7 +248,7 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    To be clear, a validator must not expect to receive all records at
    the QNAME in response to QTYPE=*.
 
-3.3.  Check for CNAME
+4.3.  Check for CNAME
 
    Section 5 of [RFC4035] says little about validating responses based
    on (or that should be based on) CNAMEs.  When validating a NOERROR/
@@ -250,7 +257,7 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    type.  Without this check, an attacker could successfully transform a
    positive CNAME response into a NOERROR/NODATA response.
 
-3.4.  Insecure Delegation Proofs
+4.4.  Insecure Delegation Proofs
 
    [RFC4035] Section 5.2 specifies that a validator, when proving a
    delegation is not secure, needs to check for the absence of the DS
@@ -263,9 +270,18 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    not signed.
 
 
-4.  Interoperability Concerns
+5.  Interoperability Concerns
 
-4.1.  Errors in Canonical Form Type Code List
+
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 5]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
+5.1.  Errors in Canonical Form Type Code List
 
    When canonicalizing DNS names, DNS names in the RDATA section of NSEC
    and RRSIG resource records are not downcased.
@@ -273,14 +289,6 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    [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.
 
@@ -288,7 +296,7 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    Since HINFO records contain no domain names, they are not subject to
    downcasing.
 
-4.2.  Unknown DS Message Digest Algorithms
+5.2.  Unknown DS Message Digest Algorithms
 
    Section 5.2 of [RFC4035] includes rules for how to handle delegations
    to zones that are signed with entirely unsupported public key
@@ -317,10 +325,18 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    disregards any DS records using unknown or unsupported message digest
    algorithms.
 
-4.3.  Private Algorithms
+5.3.  Private Algorithms
 
    As discussed above, section 5.2 of [RFC4035] requires that validators
    make decisions about the security status of zones based on the public
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 6]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    key algorithms shown in the DS records for those zones.  In the case
    of private algorithms, as described in [RFC4034] Appendix A.1.1, the
    eight-bit algorithm field in the DS RR is not conclusive about what
@@ -329,17 +345,9 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    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
+   functions, as discussed in Section 5.2).  In these cases, the
    resolver MUST retrieve the corresponding DNSKEY for each private
    algorithm DS record and examine the public key field to determine the
    algorithm in use.  The security-aware resolver MUST ensure that the
@@ -351,7 +359,7 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    This clarification facilitates the broader use of private algorithms,
    as suggested by [RFC4955].
 
-4.4.  Caution About Local Policy and Multiple RRSIGs
+5.4.  Caution About Local Policy and Multiple RRSIGs
 
    When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
    suggests that "the local resolver security policy determines whether
@@ -370,30 +378,30 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    method described in section 4.2.1.2 of [RFC4641] might not work
    reliably.
 
-4.5.  Key Tag Calculation
+5.5.  Key Tag Calculation
 
    [RFC4034] Appendix B.1 incorrectly defines the Key Tag field
    calculation for algorithm 1.  It correctly says that the Key Tag is
    the most significant 16 of the least significant 24 bits of the
    public key modulus.  However, [RFC4034] then goes on to incorrectly
    say that this is 4th to last and 3rd to last octets of the public key
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 7]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
 
-4.6.  Setting the DO Bit on Replies
+5.6.  Setting the DO Bit on Replies
 
    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.
 
-
-
-
-Weiler & Blacka         Expires September 9, 2010               [Page 7]
-
-Internet-Draft       DNSSECbis Implementation Notes           March 2010
-
-
-4.7.  Setting the AD Bit on Queries
+5.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
@@ -401,7 +409,7 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    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
+5.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
@@ -410,7 +418,7 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    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
+5.9.  Handling Queries With the CD Bit Set
 
    When processing a request with the CD bit set, a resolver SHOULD
    attempt to return all responsive data, even data that has failed
@@ -428,11 +436,20 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    up to five minutes.)  In these cases, a new query with the CD bit set
    is required.
 
-   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).
+   For efficiency, a validator SHOULD set the CD bit on 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).
 
-4.10.  Nested Trust Anchors
+
+
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 8]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
+5.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
@@ -441,24 +458,16 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    When the validator is asked to validate a response to
    "www.sub.zone.example.", either trust anchor could apply.
 
-
-
-
-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
+   described below in Section 5.10.2 while exposing other policies as
    configuration options.
 
-4.10.1.  Closest Encloser
+5.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
@@ -480,7 +489,7 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    trust anchor.  With the "closest encloser" policy, the validator gets
    validation failures.
 
-4.10.2.  Accept Any Success
+5.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
@@ -489,6 +498,13 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    or more trust anchors lead to a Bogus result and there is no Secure
    result, then the final validation result is Bogus.
 
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 9]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    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
@@ -497,17 +513,9 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    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
+5.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
@@ -532,9 +540,9 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    configured trust anchors.
 
 
-5.  Minor Corrections and Clarifications
+6.  Minor Corrections and Clarifications
 
-5.1.  Finding Zone Cuts
+6.1.  Finding Zone Cuts
 
    Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
    for a parent zone.  To do that, a resolver may first need to apply
@@ -545,22 +553,22 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    and in some situations the resolver may also need to apply special
    rules to locate the name servers for the parent zone if the resolver
    does not already have the parent's NS RRset.  Section 4.2 of
+
+
+
+Weiler & Blacka           Expires May 14, 2011                 [Page 10]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    [RFC4035] specifies a mechanism for doing that.
 
-5.2.  Clarifications on DNSKEY Usage
+6.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
@@ -579,7 +587,7 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    possible to use a single DNSKEY, with or without the SEP bit set, to
    sign the entire zone, including the DNSKEY RRset itself.
 
-5.3.  Errors in Examples
+6.3.  Errors in Examples
 
    The text in [RFC4035] Section C.1 refers to the examples in B.1 as
    "x.w.example.com" while B.1 uses "x.w.example".  This is painfully
@@ -594,12 +602,21 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    the reference to "a.z.w.w.example" should instead be "a.z.w.example",
    as in the previous line.
 
-5.4.  Errors in RFC 5155
+6.4.  Errors in RFC 5155
 
    A NSEC3 record that matches an Empty Non-Terminal effectively has no
    type associated with it.  This NSEC3 record has an empty type bit
    map.  Section 3.2.1 of [RFC5155] contains the statement:
 
+
+
+
+
+Weiler & Blacka           Expires May 14, 2011                 [Page 11]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
       Blocks with no types present MUST NOT be included.
 
    However, the same section contains a regular expression:
@@ -609,41 +626,33 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
    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:
 
       Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
 
 
-6.  IANA Considerations
+7.  IANA Considerations
 
    This document specifies no IANA Actions.
 
 
-7.  Security Considerations
+8.  Security Considerations
 
    This document adds two cryptographic features to the core DNSSEC
    protocol.  Additionally, it addresses some ambiguities and omissions
    in the core DNSSEC documents that, if not recognized and addressed in
    implementations, could lead to security failures.  In particular, the
-   validation algorithm clarifications in Section 3 are critical for
+   validation algorithm clarifications in Section 4 are critical for
    preserving the security properties DNSSEC offers.  Furthermore,
-   failure to address some of the interoperability concerns in Section 4
+   failure to address some of the interoperability concerns in Section 5
    could limit the ability to later change or expand DNSSEC, including
    adding new algorithms.
 
 
-8.  References
+9.  References
 
-8.1.  Normative References
+9.1.  Normative References
 
    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
               STD 13, RFC 1034, November 1987.
@@ -656,6 +665,14 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
 
    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "DNS Security Introduction and Requirements",
+
+
+
+Weiler & Blacka           Expires May 14, 2011                 [Page 12]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
               RFC 4033, March 2005.
 
    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
@@ -666,13 +683,6 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
               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.
 
@@ -684,7 +694,7 @@ Internet-Draft       DNSSECbis Implementation Notes           March 2010
               and RRSIG Resource Records for DNSSEC", RFC 5702,
               October 2009.
 
-8.2.  Informative References
+9.2.  Informative References
 
    [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
               Signer (DS)", RFC 3755, May 2004.
@@ -711,32 +721,33 @@ Appendix A.  Acknowledgments
    finding errors and omissions in the DNSSECbis document set, have
    provided text suitable for inclusion in this document.
 
+
+
+
+Weiler & Blacka           Expires May 14, 2011                 [Page 13]
+
+Internet-Draft       DNSSECbis Implementation Notes        November 2010
+
+
    The lack of specificity about handling private algorithms, as
-   described in Section 4.3, and the lack of specificity in handling ANY
-   queries, as described in Section 3.2, were discovered by David
+   described in Section 5.3, and the lack of specificity in handling ANY
+   queries, as described in Section 4.2, were discovered by David
    Blacka.
 
    The error in algorithm 1 key tag calculation, as described in
-   Section 4.5, was found by Abhijit Hayatnagarkar.  Donald Eastlake
-   contributed text for Section 4.5.
-
-   The bug relating to delegation NSEC RR's in Section 3.1 was found by
-
-
-
-Weiler & Blacka         Expires September 9, 2010              [Page 13]
-
-Internet-Draft       DNSSECbis Implementation Notes           March 2010
-
+   Section 5.5, was found by Abhijit Hayatnagarkar.  Donald Eastlake
+   contributed text for Section 5.5.
 
+   The bug relating to delegation NSEC RR's in Section 4.1 was found by
    Roy Badami.  Roy Arends found the related problem with DNAME.
 
    The errors in the [RFC4035] examples were found by Roy Arends, who
-   also contributed text for Section 5.3 of this document.
+   also contributed text for Section 6.3 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.
+   Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
+   and Scott Rose for their substantive comments on the text of this
+   document.
 
 
 Authors' Addresses
@@ -769,17 +780,6 @@ Authors' Addresses
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka         Expires September 9, 2010              [Page 14]
+Weiler & Blacka           Expires May 14, 2011                 [Page 14]
 
 

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

@@ -1,448 +0,0 @@
-DNS Extensions working group                             V.Dolmatov, Ed.  
-Internet-Draft                                            Cryptocom Ltd.    
-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-07
-
-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 06 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 
-   (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 (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
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  Using a public key with existing cryptographic libraries. . 3
-     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 3
-   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
-     3.1 RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . . 4
-   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
-     4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
-     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5
-     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 5
-     6.1.  Support for GOST signatures . . . . . . . . . . . . . . . . 5
-     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
-     6.3.  Byte order  . . . . . . . . . . . . . . . . . . . . . . . . 5
-   7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
-   10.  References   . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
-     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical distributed
-   database for Internet Naming.  The DNS has been extended to use
-   cryptographic keys and digital signatures for the verification of the
-   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
-   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
-   Extensions, called DNSSEC.
-
-   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
-   and specifies a list of cryptographic algorithms to use.  This
-   document extends that list with the signature and hash algorithms 
-   GOST [GOST3410, GOST3411],
-   and specifies how to store DNSKEY data and how to produce
-   RRSIG resource records with these hash algorithms.
-
-   Familiarity with DNSSEC  and GOST signature and hash
-   algorithms is assumed in this document.
-
-   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[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.
-
-   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].
-
-V.Dolmatov              Expires September 06, 2010             [Page 2]
-
-2.  DNSKEY Resource Records
-
-   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
-
-   GOST R 34.10-2001 public keys are stored with the algorithm number 
-   {TBA1}.
-      
-   The wire format of the public key is compatible with 
-   RFC 4491 [RFC4491]:
-
-   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 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.
-
-   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
-   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
-
-2.1.  Using a public key with existing cryptographic libraries
-
-   Existing GOST-aware cryptographic libraries at the time of this 
-   document writing are capable to read GOST public keys via a generic
-   X509 API if the key is encoded according to RFC 4491 [RFC4491],
-   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 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
-   0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
-  
-2.2.  GOST DNSKEY RR Example
-
-   Given a private key with the following value (the value of GostAsn1
-   field is split here into two lines to simplify reading; in the 
-   private key file it must be in one line):
-
-   Private-key-format: v1.2
-   Algorithm: {TBA1} (ECC-GOST)
-   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c
-             t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA=
- 
-
-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} (
-                                GtTJjmZKUXV+lHLG/6crB6RCR+EJR51Islpa
-                                6FqfT0MUfKhSn1yAo92+LJ0GDssTiAnj0H0I
-                                9Jrfial/yyc5Og==
-                                ) ; key id = 10805
-
-3.  RRSIG Resource Records
-
-   The value of the signature field in the RRSIG RR follows RFC 4490
-   [RFC4490] and is calculated as follows.  The values for the RDATA 
-   fields that precede the signature data are specified 
-   in RFC 4034 [RFC4034].
-
-   hash = GOSTR3411(data)
-
-   where "data" is the wire format data of the resource record set 
-   that is signed, as specified in RFC 4034 [RFC4034].
-   
-   Hash MUST be calculated with GOST R 34.11-94 parameters identified
-   by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-   Signature is calculated from the hash according to the 
-   GOST R 34.10-2001 standard and its wire format is compatible with 
-   RFC 4490 [RFC4490].
-
-   Quoting RFC 4490:
-
-   "The signature algorithm GOST R 34.10-2001 generates a digital
-   signature in the form of two 256-bit numbers, r and s.  Its octet
-   string representation consists of 64 octets, where the first 32
-   octets contain the big-endian representation of s and the second 32
-   octets contain the big-endian representation of r."
-
-3.1. RRSIG RR Example
-
-   With the private key from section 2.2 sign the following RRSet, 
-   consisting of one A record:
-
-   www.example.net. 3600 IN A 192.0.2.1
-
-   Setting the inception date to 2000-01-01 00:00:00 UTC and the 
-   expiration date to 2030-01-01 00:00:00 UTC, the following signature
-   should be created (assuming {TBA1}==249 until proper code is 
-   assigned by IANA)
-
-   www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
-                                  20000101000000 10805 example.net.
-                                  k3m0r5bm6kFQmcRlHshY3jIj7KL6KTUsPIAp
-                                  Vy466khKuWEUoVvSkqI+9tvMQySQgZcEmS0W
-                                  HRFSm0XS5YST5g== )
- 
-V.Dolmatov              Expires September 06, 2010             [Page 4]
-
-  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
-
-   GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
-   type {TBA2}.The wire format of a digest value is compatible with 
-   RFC4490 [RFC4490], that is digest is in little-endian representation. 
-
-
-   The digest MUST always be calculated with GOST R 34.11-94 parameters
-   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-4.1. DS RR Example
-
-   For key signing key (assuming {TBA1}==249 until proper code is 
-   assigned by IANA)
-
-   example.net. 86400   DNSKEY  257 3 {TBA1} (
-                                1aYdqrVz3JJXEURLMdmeI7H1CyTFfPVFBIGA
-                                EabZFP+7NT5KPYXzjDkRbPWleEFbBilDNQNi
-                                q/q4CwA4WR+ovg==
-                                ) ; key id = 6204
- 
-   The DS RR will be
-
-   example.net. 3600 IN DS 6204 {TBA1} {TBA2} (
-             0E6D6CB303F89DBCF614DA6E21984F7A62D08BDD0A05B3A22CC63D1B
-             553BC61E )
-
-5.  Deployment Considerations
-
-5.1.  Key Sizes
-
-   According to RFC4357 [RFC4357], the key size of GOST public keys
-   MUST be 512 bits.
-
-5.2.  Signature Sizes
-
-   According to the GOST signature algorithm specification [GOST3410],
-   the size of a GOST signature is 512 bits.
-
-5.3.  Digest Sizes
-
-   According to the GOST R 34.11-94 [GOST3411], the size of a GOST 
-   digest is 256 bits.
-
-6.  Implementation Considerations
-
-6.1.  Support for GOST signatures
-
-   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 September 06, 2010             [Page 5]
-
-6.2.  Support for NSEC3 Denial of Existence
-
-    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 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
-
-    Currently, the cryptographic resistance of the GOST 34.10-2001 
-    digital signature algorithm is estimated as 2**128 operations
-    of multiple elliptic curve point computations on prime modulus
-    of order 2**256.
-
-
-    Currently, the cryptographic resistance of GOST 34.11-94 hash
-    algorithm is estimated as 2**128 operations of computations of a
-    step hash function. (There is known method to reduce this 
-    estimate to 2**105 operations, but it demands padding the 
-    colliding message with 1024 random bit blocks each of 256 bit
-    length, thus it cannot be used in any practical implementation).
-
-8.  IANA Considerations
-
-   This document updates the IANA registry "DNS Security Algorithm 
-   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 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
-   algorithm:
-
-   Value   Algorithm        Status
-   {TBA2}  GOST R 34.11-94  OPTIONAL
-
-9. Acknowledgments
-
-   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
-   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
-   and RFC 4357 [RFC4357] for consistency. The authors of and 
-   contributors to these documents are gratefully acknowledged for 
-   their hard work.
-
-V.Dolmatov              Expires September 06, 2010             [Page 6]
-
-   The following people provided additional feedback and text: Dmitry 
-   Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen 
-   and Wouter Wijngaards.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-   [RFC3110]  Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-              Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC4033]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [GOST3410] "Information technology.  Cryptographic data security.
-              Signature and verification processes of [electronic]
-              digital signature.", GOST R 34.10-2001, Gosudarstvennyi
-              Standard of Russian Federation, Government Committee of
-              the Russia for Standards, 2001.  (In Russian)
-
-   [GOST3411] "Information technology.  Cryptographic Data Security.
-              Hashing function.", GOST R 34.11-94, Gosudarstvennyi
-              Standard of Russian Federation, Government Committee of
-              the Russia for Standards, 1994.  (In Russian)
-
-   [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional
-             Cryptographic Algorithms for Use with GOST 28147-89,
-             GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
-             Algorithms", RFC 4357, January 2006.
-
-   [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, 
-             GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 
-             Algorithms with Cryptographic Message Syntax (CMS)",
-             RFC 4490, May 2006.
-
-   [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST 
-             R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 
-             Algorithms with the Internet X.509 Public Key 
-             Infrastructure Certificate and CRL Profile", RFC 4491,
-             May 2006. 
-
-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
-
-   [RFC4509]  Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [DRAFT1]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
-              "GOST R 34.10-2001 digital signature algorithm"
-              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-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-08, 12.12.09
-              work in progress.
-
-V.Dolmatov              Expires September 06, 2010             [Page 8]
-
-
-Authors' Addresses
-
-
-Vasily Dolmatov, Ed.
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: dol@cryptocom.ru
-
-Artem Chuprina
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: ran@cryptocom.ru
-
-Igor Ustinov
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: igus@cryptocom.ru
-
-V.Dolmatov              Expires September 06, 2010             [Page 9]
-

doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt

@@ -0,0 +1,448 @@
+
+
+
+DNS Extensions Working Group                                     S. Rose
+Internet-Draft                                                      NIST
+Updates: 2536, 2539, 3110, 4034,                         August 11, 2010
+4398, 5155, 5702, 5933
+(if approved)
+Intended status: Standards Track
+Expires: February 12, 2011
+
+
+  Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
+                                Registry
+               draft-ietf-dnsext-dnssec-registry-fixes-06
+
+Abstract
+
+   The DNS Security Extensions (DNSSEC) requires the use of
+   cryptographic algorithm suites for generating digital signatures over
+   DNS data.  There is currently an IANA registry for these algorithms
+   that is incomplete in that it lacks the implementation status of each
+   algorithm.  This document provides an applicability statement on
+   algorithm status for DNSSEC implementations.  This document replaces
+   that registry table with a new IANA registry table for Domain Name
+   System Security (DNSSEC) Algorithm Numbers which lists each
+   algorithm's status based on the current reference.  If that status is
+   not defined in the original specification, this document assigns a
+   status.
+
+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.
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 1]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+   This Internet-Draft will expire on February 12, 2011.
+
+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
+   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.  The DNS Security Algorithm Number Subregistry . . . . . . . . . 3
+     2.1.  Individual Changes  . . . . . . . . . . . . . . . . . . . . 3
+     2.2.  Domain Name System (DNS) Security Algorithm Number
+           Registry Table  . . . . . . . . . . . . . . . . . . . . . . 5
+     2.3.  Specifying New Algorithms and Updating Status of
+           Existing Entries  . . . . . . . . . . . . . . . . . . . . . 6
+
+   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
+     5.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 2]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+1.  Introduction
+
+   The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033],
+   [RFC4034], and [RFC4035] uses digital signatures over DNS data to
+   provide source authentication and integrity protection.  DNSSEC uses
+   an IANA registry to allocate codes for digital signature algorithms
+   (consisting of a cryptographic algorithm and one-way hash function).
+
+   The original list of algorithm status is found in [RFC4034].  Other
+   DNSSEC documents have added new algorithms or changed the status of
+   algorithms in the registry.  However, currently implementors must
+   read through all the documents in order to discover the current
+   status of each algorithm in the registry.
+
+   This document replaces the current IANA registry for Domain Name
+   System Security (DNSSEC) Algorithm Numbers with a newly defined
+   registry table.  This new table (Section 2.2 below) contains a column
+   that will list the current status of each digital signature algorithm
+   in the registry at the time of writing and assigns status for some
+   algorithms used with DNSSEC that did not have an identified status in
+   their specification.  This document updates the following: [RFC2536],
+   [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and
+   [RFC5933].
+
+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 [RFC2119].
+
+2.  The DNS Security Algorithm Number Subregistry
+
+   The DNS Security Algorithm Number subregistry (part of the Domain
+   Name System (DNS) Security Number registry) will be replaced with the
+   table below.  This table contains a column that contains the current
+   implementation requirements of the given algorithm.
+
+   There are additional differences to entries that are described in
+   sub-section 2.1.  The overall new registry table is in sub-section
+   2.2.  The values for the status were obtained from [RFC4034] with
+   updates for algorithms specified after the original DNSSEC
+   specification.  If no status was listed in the original
+   specification, this document assigns one.
+
+2.1.  Individual Changes
+
+   This document changes three entries in the Domain Name System
+   Security (DNSSEC) Algorithm Registry.  They are:
+
+
+
+Rose                    Expires February 12, 2011               [Page 3]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+   The description for assignment number 4 is changed to "Reserved until
+   2020".
+
+   The description for assignment number 9 is changed to "Reserved until
+   2020".
+
+   The description for assignment number 11 is changed to "Reserved
+   until 2020".
+
+   Registry entries 13-251 remains Unassigned.
+
+   The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are set to
+   RECOMMENDED and OPTIONAL respectively.  The difference is due to the
+   fact that RSA/SHA-1 is REQUIRED and DSA/SHA-1 is only OPTIONAL.  The
+   status of RSA/SHA-256 and RSA/SHA-512 are set to RECOMMENDED as it is
+   believed that these algorithms will replace older algorithms (e.g.
+   RSA/SHA-1) that have a perceived weakness in their hash algorithm
+   (SHA-1).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 4]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+2.2.  Domain Name System (DNS) Security Algorithm Number Registry Table
+
+   The Domain Name System (DNS) Security Algorithm Number registry is
+   hereby specified as follows:
+
+                                  Zone  Transaction
+Number  Description    Mnemonic   Sign  Sign     Status       Reference
+------  -----------     ------    ----  -----  ------------   ---------
+  0      Reserved                                             [RFC4398]
+  1      RSA/MD5         RSAMD5     N     Y     MUST NOT      [RFC4034],
+                                                IMPLEMENT     [RFC3110]
+                                                             (this memo)
+  2      Diffie-Hellman   DH        N     Y                   [RFC2539]
+                                                             (this memo)
+  3      DSA/SHA-1       DSASHA1    Y     Y                   [RFC2536],
+                                                              [RFC4034],
+                                                             FIPS 186-3,
+                                                             FIPS 180-3
+                                                             (this memo)
+  4      Reserved until   ECC                                (this memo)
+         2020
+  5      RSA/SHA-1       RSASHA1    Y     Y     REQUIRED      [RFC4034]
+                                                             (this memo)
+  6      DSA-NSEC3-SHA1  DSA-NSEC3  Y     Y                   [RFC5155]
+                         -SHA1                               (this memo)
+  7      RSASHA1-NSEC3   RSASHA1-   Y     Y    RECOMMENDED    [RFC5155]
+         -SHA1           NSEC3-                              (this memo)
+                         SHA1
+  8      RSA/SHA-256     RSASHA256  Y     *    RECOMMENDED     [RFC5702]
+                                                             (this memo)
+  9      Reserved until                                      (this memo)
+         2020
+ 10      RSA/SHA-512     RSASHA512  Y     *    RECOMMENDED    [RFC5702]
+                                                             (this memo)
+ 11      Reserved until                                      (this memo)
+         2020
+ 12      GOST R          GOST-ECC   Y     *                   [RFC5933]
+         34.10-2001                                          (this memo)
+13-251   Unassigned
+ 252     Reserved for    INDIRECT   N     N                   [RFC4034]
+         Indirect keys                                       (this memo)
+ 253     private         PRIVATE    Y     Y                   [RFC4034]
+         algorithm                                           (this memo)
+ 254     private         PRIVATEOID Y     Y                   [RFC4034]
+         algorithm OID                                       (this memo)
+ 255     Reserved
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 5]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+2.3.  Specifying New Algorithms and Updating Status of Existing Entries
+
+   [I-D.ietf-dnsext-dnssec-alg-allocation] establishes a parallel
+   procedure for obtaining an algorithm number for new algorithms other
+   than a standards track document.  Algorithms entered into the
+   registry using that procedure do not have a listed status.
+   Specifications that follow this path do not need to obsolete or
+   update this document.
+
+   Adding a newly specified algorithm to the registry with a status
+   SHALL entail obsoleting this document and replacing the registry
+   table (with the new algorithm entry).  Altering the status column
+   value of any existing algorithm in the registry SHALL entail
+   obsoleting this document and replacing the registry table.
+
+   This document cannot be updated, only made obsolete and replaced by a
+   successor document.
+
+3.  IANA Considerations
+
+   This document replaces the Domain Name System (DNS) Security
+   Algorithm Numbers registry.  The new registry table is in Section
+   2.2.
+
+   The original Domain Name System (DNS) Security Algorithm Number
+   registry is available at http://www.iana.org/assignments/
+   dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml.
+
+4.  Security Considerations
+
+   This document replaces the Domain Name System (DNS) Security
+   Algorithm Numbers registry.  It is not meant to be a discussion on
+   algorithm superiority.  No new security considerations are raised in
+   this document.
+
+5.  References
+
+5.1.  Normative References
+
+   [I-D.ietf-dnsext-dnssec-alg-allocation]  Hoffman, P., "Cryptographic
+                                            Algorithm Identifier
+                                            Allocation for DNSSEC", draf
+                                            t-ietf-dnsext-dnssec-alg-
+                                            allocation-03 (work in
+                                            progress), March 2010.
+
+   [RFC2119]                                Bradner, S., "Key words for
+                                            use in RFCs to Indicate
+
+
+
+Rose                    Expires February 12, 2011               [Page 6]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+                                            Requirement Levels", BCP 14,
+                                            RFC 2119, March 1997.
+
+   [RFC2536]                                Eastlake, D., "DSA KEYs and
+                                            SIGs in the Domain Name
+                                            System (DNS)", RFC 2536,
+                                            March 1999.
+
+   [RFC2539]                                Eastlake, D., "Storage of
+                                            Diffie-Hellman Keys in the
+                                            Domain Name System (DNS)",
+                                            RFC 2539, March 1999.
+
+   [RFC3110]                                Eastlake, D., "RSA/SHA-1
+                                            SIGs and RSA KEYs in the
+                                            Domain Name System (DNS)",
+                                            RFC 3110, May 2001.
+
+   [RFC4033]                                Arends, R., Austein, R.,
+                                            Larson, M., Massey, D., and
+                                            S. Rose, "DNS Security
+                                            Introduction and
+                                            Requirements", RFC 4033,
+                                            March 2005.
+
+   [RFC4034]                                Arends, R., Austein, R.,
+                                            Larson, M., Massey, D., and
+                                            S. Rose, "Resource Records
+                                            for the DNS Security
+                                            Extensions", RFC 4034,
+                                            March 2005.
+
+   [RFC4035]                                Arends, R., Austein, R.,
+                                            Larson, M., Massey, D., and
+                                            S. Rose, "Protocol
+                                            Modifications for the DNS
+                                            Security Extensions",
+                                            RFC 4035, March 2005.
+
+   [RFC4398]                                Josefsson, S., "Storing
+                                            Certificates in the Domain
+                                            Name System (DNS)",
+                                            RFC 4398, March 2006.
+
+   [RFC5155]                                Laurie, B., Sisson, G.,
+                                            Arends, R., and D. Blacka,
+                                            "DNS Security (DNSSEC)
+                                            Hashed Authenticated Denial
+
+
+
+Rose                    Expires February 12, 2011               [Page 7]
+
+Internet-Draft             IANA Registry Fixes               August 2010
+
+
+                                            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.
+
+   [RFC5933]                                Dolmatov, V., Chuprina, A.,
+                                            and I. Ustinov, "Use of GOST
+                                            Signature Algorithms in
+                                            DNSKEY and RRSIG Resource
+                                            Records for DNSSEC",
+                                            RFC 5933, July 2010.
+
+5.2.  Informative References
+
+   [FIPS.180-3.2008]                        National Institute of
+                                            Standards and Technology,
+                                            "Secure Hash Standard",
+                                            FIPS PUB 180-3,
+                                            October 2008, <http://
+                                            csrc.nist.gov/publications/
+                                            fips/fips180-3/
+                                            fips180-3.pdf>.
+
+   [FIPS.186-3.2009]                        National Institute of
+                                            Standards and Technology,
+                                            "Digital Signature
+                                            Standard", FIPS PUB 186-3,
+                                            June 2009, <http://
+                                            csrc.nist.gov/publications/
+                                            fips/fips186-3/
+                                            fips_186-3.pdf>.
+
+Author's Address
+
+   Scott Rose
+   NIST
+   100 Bureau Dr.
+   Gaithersburg, MD  20899
+   USA
+
+   Phone: +1-301-975-8439
+   EMail: scottr.nist@gmail.com
+
+
+
+
+
+Rose                    Expires February 12, 2011               [Page 8]
+

doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt

@@ -0,0 +1,336 @@
+
+
+
+Domain Name System Operations                                 W. Mekking
+Internet-Draft                                                NLnet Labs
+Intended status: Standards Track                           June 29, 2010
+Expires: December 31, 2010
+
+
+    Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE
+                   draft-mekking-dnsop-auto-cpsync-00
+
+Abstract
+
+   This document proposes a way to synchronise existing trust anchors
+   automatically between a child zone and its parent.  The algorithm can
+   be used for other Resource Records that are required to delegate from
+   a parent to a child such as NS and glue records.
+
+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 in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   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."
+
+   This Internet-Draft will expire on December 31, 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
+
+
+
+Mekking                 Expires December 31, 2010               [Page 1]
+
+Internet-Draft        Child Parent Synchronization             June 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 Simplified BSD License.
+
+1.  Introduction
+
+   This memo defines a way to synchronise existing trust anchors
+   automatically between a child zone and its parent.  The algorithm can
+   be used for other Resource Records that are required to delegate from
+   a parent to a child such as NS and glue records.
+
+   To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones
+   must submit their DNSKEYs, or hashes of their DNSKEYs, to their
+   parent zone.  The parent zone publishes the hashes of the DNSKEYs in
+   the form of a DS record.  The DNSKEY RRset at the child may change
+   over time.  In order to keep the chain of trust intact, the DS
+   records at the parent zone also needs to be updated.  The rolling of
+   the keys with the SEP bit on is one of the few tasks in DNSSEC that
+   yet has to be fully automated.
+
+   The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone
+   changes to the parent.
+
+   To bootstrap the direct communication channel, information must be
+   exchanged in order to detect service location and granting update
+   privileges.  A new or existing child zone can request a direct
+   communication channel with the parent.  If the parent allows for
+   direct communication with child zones, the parent can share the
+   required data to set up the channel to the child zone.  Once the
+   child has the required credentials, it can use the direct
+   communication channel with the parent to request zone changes related
+   to its delegation.
+
+   If a third party is involved, the third party can act on behalf of
+   the parent.  In this case, the third party will give out the required
+   credentials to set up the communication channel.
+
+   It is RECOMMENDED that the direct communication channel is secured
+   with TSIG [RFC2845] or SIG0 [RFC2931].
+
+2.  Access and Update Control
+
+   The DNS UPDATE normally is used for granting update permissions to a
+   machine that is within the boundary of the same organization.  This
+   document proposes to grant child zones the same permissions.
+   However, it MUST NOT be possible that a child zone updates
+
+
+
+Mekking                 Expires December 31, 2010               [Page 2]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   information in the parent zone that falls outside the administrative
+   domain of the corresponding delegation.  For example, it MUST NOT be
+   possible for a child zone to update the data that the parent is
+   authoritative for, or update a delegation that is pointed to a
+   different child zone.  It MUST only be able to update records that
+   match one of the following:
+
+   Or:   The owner name is equal the child zone name and RRtype is
+      delegation specific.  Currently those are records with RRtype NS
+      or DS.
+
+   Or:   The owner name is a subdomain of the child zone name and RRtype
+      is glue specific.  Currently those are records with RRtype A or
+      AAAA.
+
+   This list may be expanded in the future, if there is need for more
+   delegation related zone content.
+
+   In case of adding or deleting delegation specific records, the DNSSEC
+   related RRs in the parent zone might need to be updated.
+
+   The service location may be handed out by the registrar during
+   bootstrap If this information is missing, the normal guidelines for
+   sending DNS UPDATE messages SHOULD be followed.
+
+3.  Update Mechanism
+
+3.1.  Child Duties
+
+   Updating the NS RRset or corresponding glue at the parent, an update
+   can be sent at any time.  Updating the DS RRset is part of key
+   rollover, as described in RFC 4641 [RFC4641].  When performing a key
+   rollover that involves updating the RRset at the parent, the child
+   introduces a new DNSKEY in its zone that represents the security
+   entry point for determining the chain of trust.  After a while, it
+   will revoke and/or remove the previous security entry point.  The
+   timings when to update the DS RRset at the parent are described in
+   draft-dnsop-morris-dnssec-key-timing [keytiming].  When updating the
+   DS RRset at the parent automatically, these timing specifications
+   SHOULD be followed.  To determine the propagation delays described in
+   this document, the child should poll the parent zone for a short
+   time, until the DS is visible at all parent name servers.
+
+   To discuss: A child zone might be unable to reach all parent name
+   servers.
+
+   The child notifies the parent of the requested changes by sending a
+   DNS UPDATE message.  If it receives a NOERROR reply in return, the
+
+
+
+Mekking                 Expires December 31, 2010               [Page 3]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   update is acknowledged by the parent zone.  Otherwise, the child MAY
+   retry transmitting the update.  In order to prevent duplicate
+   updates, it SHOULD follow the guidelines described in RFC 2136
+   [RFC2136].
+
+3.2.  Parent Duties
+
+   When the master DNS server of the parent receives a DNS UPDATE from
+   one of its children the following must be done:
+
+   Step 1:  Check the TSIG/SIG0 credentials.  In case of TSIG, the
+      parent should follow the TSIG processing described in section 3.2
+      of RFC 2845.  In case of SIG0, the parent should follow the SIG0
+      processing described in section 3.2 of RFC 2931.
+
+   Step 2:  Verify that the updates matches the update policy for child
+      zones.
+
+   Step 3:  If verified, send back DNS UPDATE OK.  Otherwise, send back
+      DNS UPDATE REFUSED.
+
+   Step 4:  If verified, apply changes.  How that is done is a matter of
+      policy.
+
+3.3.  Proxy considerations
+
+   Some environments don't allow for direct communication between parent
+   and child zone.  In these case, the parent duties can be performed by
+   a different party (for example, the registar).  The third party will
+   forward the update to the parent zone.  In what format depends on
+   local policy.
+
+4.  Example BIND9 Configuration
+
+   This is how a parent zone can configure a policy to enable a child
+   zone synchronize delegation specific records.  The first rule of the
+   update policy grants children to update their DS and NS records in
+   the parent zone, in this case example.com.  The second rule of the
+   update policy grants children to update the corresponding glue
+   records.
+
+   key cs.example.com. {
+   algorithm HMAC-MD5;
+   secret "secretforcs";
+   }
+
+   key math.example.com. {
+   algorithm HMAC-MD5;
+
+
+
+Mekking                 Expires December 31, 2010               [Page 4]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+   secret "secretformath";
+   }
+
+   ...
+
+   zone "example.com" {
+   type master;
+   file "example.com";
+   update-policy { grant *.example.com. self *.example.com.  DS NS; };
+   update-policy { grant *.example.com. selfsub *.example.com.  A AAAA;
+   };
+   };
+
+5.  Security Considerations
+
+   Automating the synchronization of (DNSSEC) records between the parent
+   and child created a new channel.  We have recommended that this
+   channel should be secured with TSIG or SIG0.  There is an advantage
+   and a disadvantage of the new security channel.  The disadvantage is
+   that you create a new attack window for your DNSSEC credentials.  If
+   the automated synchronization is used for updating DS records at the
+   parent, you SHOULD pick a cryptographically an equally strong or
+   stronger TSIG/SIG0 key than the strength of your DNSSEC keys.
+
+   The advantage is that if somehow your DNSSEC keys are compromised,
+   you can still use this channel to perform an emergency key rollover.
+
+6.  IANA Considerations
+
+   None.
+
+7.  Acknowledgments
+
+   Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards and more.
+
+8.  References
+
+8.1.  Informative References
+
+   [RFC2136]    Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+                "Dynamic Updates in the Domain Name System (DNS
+                UPDATE)", RFC 2136, April 1997.
+
+   [RFC4641]    Kolkman, O. and R. Gieben, "DNSSEC Operational
+                Practices", RFC 4641, September 2006.
+
+   [keytiming]  Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
+                Timing Considerations", March 2010.
+
+
+
+Mekking                 Expires December 31, 2010               [Page 5]
+
+Internet-Draft        Child Parent Synchronization             June 2010
+
+
+8.2.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                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.
+
+   [RFC2931]    Eastlake, D., "DNS Request and Transaction Signatures (
+                SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC4035]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
+                Rose, "Protocol Modifications for the DNS Security
+                Extensions", RFC 4035, March 2005.
+
+Author's Address
+
+   Matthijs Mekking
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   EMail: matthijs@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mekking                 Expires December 31, 2010               [Page 6]
+

doc/draft/draft-yao-dnsext-bname-04.txt

@@ -0,0 +1,729 @@
+
+
+Network Working Group                                             J. Yao
+Internet-Draft                                                    X. Lee
+Intended status: Standards Track                                   CNNIC
+Expires: February 12, 2011                                      P. Vixie
+                                            Internet Software Consortium
+                                                         August 11, 2010
+
+
+                      Bundle DNS Name Redirection
+                     draft-yao-dnsext-bname-04.txt
+
+Abstract
+
+   This document defines a new DNS Resource Record called "BNAME", which
+   provides the capability to map itself and its subtree of the DNS name
+   space to another domain.  It differs from the CNAME record which only
+   maps a single node of the DNS name space, from the DNAME which only
+   maps the subtree of the DNS name space to another domain.
+
+Status of this Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   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."
+
+   This Internet-Draft will expire on February 12, 2011.
+
+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
+   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
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 1]
+
+Internet-Draft                    bname                      August 2010
+
+
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  The BNAME Resource Record  . . . . . . . . . . . . . . . . . .  4
+     3.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  The BNAME Substitution . . . . . . . . . . . . . . . . . .  4
+     3.3.  The BNAME Rules  . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Query Processing . . . . . . . . . . . . . . . . . . . . . . .  4
+     4.1.  Processing by Servers  . . . . . . . . . . . . . . . . . .  5
+     4.2.  Processing by Resolvers  . . . . . . . . . . . . . . . . .  8
+   5.  BNAME in DNSSEC  . . . . . . . . . . . . . . . . . . . . . . .  9
+     5.1.  BNAME validating . . . . . . . . . . . . . . . . . . . . .  9
+     5.2.  BNAME alias algorithm identifiers  . . . . . . . . . . . . 10
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+   9.  Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
+     9.1.  draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 11
+     9.2.  draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 11
+     9.3.  draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 11
+     9.4.  draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 11
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 2]
+
+Internet-Draft                    bname                      August 2010
+
+
+1.  Introduction
+
+   More and more internationalized domain name labels [RFC3490] appear
+   in the DNS trees.  Some labels [RFC3743] are equivalent in some
+   languages.  The internet users want them to be identical in the DNS
+   resolution.  For example, color.exmaple.com==colour.example.com.  The
+   BNAME represents for bundle names.  This document defines a new DNS
+   Resource Record called "BNAME", which provides the capability to map
+   an entire tree of the DNS name space to another domain.  It means
+   that the BNAME redirects both itself and its descendants to its
+   owner.  The DNAME [RFC2672] and [RFC2672bis] do not redirect itself,
+   only the descendants.  The domain name that owns a DNAME record is
+   allowed to have other resource record types at that domain name.  The
+   domain name that owns a BNAME record is not allowed to have other
+   resource record types at that domain name unless they are the DNSSEC
+   related resource record types defined in [RFC4033], [RFC4034],
+   [RFC4035] and [RFC5155].  A server MAY refuse to load a zone that has
+   data at a sub-domain of a domain name owning a BNAME RR or that has
+   other data except the DNSSEC related resource record types and BNAME
+   at that name.  BNAME is a singleton type, meaning only one BNAME is
+   allowed per name except the DNSSEC related resource record types.
+   Resolvers, servers and zone content administrators should be cautious
+   that usage of BNAME or its combination with CNAME or DNAME may lead
+   to form loops.  The loops should be avoided.
+
+1.1.  Terminology
+
+   All the basic terms used in this specification are defined in the
+   documents [RFC1034], [RFC1035] and [RFC2672].
+
+
+2.  Motivation
+
+   In some languages, some characters have the variants, which look
+   differently or very similar but are identical in the meaning.  For
+   example, Chinese character U+56FD and its variant U+570B look
+   differently, but are identical in the meaning.  If Internationalized
+   Domain Label" or "IDL" [RFC3743] are composed of variant characters,
+   we regard this kind of IDL as the IDL variant.  If these IDL variants
+   are put into the DNS for resolution, they are expected to be
+   identical in the DNS resolution.  More comprehensible example is that
+   we expect color.exmaple.com to be equivalent with the
+   colour.exmaple.com in the DNS resolution.  The BNAME Resource Record
+   and its processing rules are conceived as a solution to this
+   equivalence problem.  Without the BNAME mechanism, current mechanisms
+   such as DNAME or CNAME are not enough capable to solve all the
+   problems with the emergence of internationalized domain names.  The
+   internationalized domain names may have alias or equivalence of the
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 3]
+
+Internet-Draft                    bname                      August 2010
+
+
+   original one.  The BNAME solution provides the solution to both ASCII
+   alias names and internationalized domain alias names.
+
+
+3.  The BNAME Resource Record
+
+3.1.  Format
+
+   The BNAME RR has mnemonic BNAME and type code xx (decimal).  It is
+   not class-sensitive.  Its RDATA is comprised of a single field,
+   <target>, which contains a fully qualified domain name that must be
+   sent in uncompressed form [RFC1035], [RFC3597].  The <target> field
+   MUST be present.  The presentation format of <target> is that of a
+   domain name [RFC1035].  The wildcards in the BNAME RR SHOULD NOT be
+   used.
+
+     <owner> <ttl> <class> BNAME <target>
+
+   The effect of the BNAME 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 BNAME RR found in the
+   resolution process, which allows fairly lengthy valid chains of BNAME
+   RRs.
+
+3.2.  The BNAME Substitution
+
+   A BNAME substitution is performed by replacing the suffix labels of
+   the name being sought matching the owner name of the BNAME resource
+   record with the string of labels in the RDATA field.  The matching
+   labels end with the root label in all cases.  Only whole labels are
+   replaced.
+
+3.3.  The BNAME Rules
+
+   There are two rules which governs the use of BNAMEs in a zone file.
+   The first one is that there SHOULD be no descendants under the owner
+   of the BNAME.  The second one is that no resource records can co-
+   exist with the BNAME for the same name except the DNSSEC related
+   resource record types.  It means that if a BNAME RR is present at a
+   node N, there MUST be no other data except the DNSSEC related
+   resource record types at N and no data at any descendant of N. This
+   restriction applies only to records of the same class as the BNAME
+   record.
+
+
+4.  Query Processing
+
+   To exploit the BNAME mechanism the name resolution algorithms
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 4]
+
+Internet-Draft                    bname                      August 2010
+
+
+   [RFC1034] must be modified slightly for both servers and resolvers.
+   Both modified algorithms incorporate the operation of making a
+   substitution on a name (either QNAME or SNAME) under control of a
+   BNAME record.  This operation will be referred to as "the BNAME
+   substitution".
+
+4.1.  Processing by Servers
+
+   For a server performing non-recursive service steps 3.a, 3.c and 4 of
+   section 4.3.2 [RFC1034] are changed to check for a BNAME record, and
+   to return certain BNAME records from zone data and the cache.
+
+   If the owner name of the bname is the suffix of the name queryed but
+   different, when preparing a response, a server performing a BNAME
+   substitution will in all cases include the relevant BNAME RR in the
+   answer section.  A CNAME RR is synthesized and included in the answer
+   section.  This will help the client to reach the correct DNS data.
+
+   If the owner name of the bname is same with the name queryed, when
+   preparing a response, a server performing a BNAME substitution will
+   not include the relevant BNAME RR in the answer section unless the
+   type queryed is BNAME.  A CNAME RR will be synthesized and included
+   in the answer section unless the type queryed is BNAME or the query
+   is the DNSSEC query.
+
+   The provided synthesized CNAME RR if there has one, MUST have
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 5]
+
+Internet-Draft                    bname                      August 2010
+
+
+      The same CLASS as the QCLASS of the query,
+
+      TTL equal to the corresponding BNAME RR,
+
+      An <owner> equal to the QNAME in effect at the moment the BNAME RR
+      was encountered, and
+
+      An RDATA field containing the new QNAME formed by the action of
+      the BNAME substitution.
+
+
+   The revised server algorithm is:
+
+
+   1. Set or clear the value of recursion available in the response
+      depending on whether the name server is willing to provide
+      recursive service.  If recursive service is available and
+      requested via the RD bit in the query, go to step 5, otherwise
+      step 2.
+
+   2. Search the available zones for the zone which is the nearest
+      ancestor to QNAME.  If such a zone is found, go to step 3,
+      otherwise step 4.
+
+   3. Start matching down, label by label, in the zone.  The matching
+      process can terminate several ways:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 6]
+
+Internet-Draft                    bname                      August 2010
+
+
+     a. If the whole of QNAME is matched, we have found the node.
+
+         If the data at the node is a CNAME, and QTYPE doesn't match
+         CNAME, copy the CNAME RR into the answer section of the
+         response, change QNAME to the canonical name in the CNAME RR,
+         and go back to step 1.
+
+         If the data at the node is a BNAME, and QTYPE doesn't
+         match BNAME, copy the BNAME RR and also a corresponding,
+         synthesized CNAME RR into the answer section of the
+         response, change QNAME to the name carried as RDATA in
+         the BNAME RR, and go back to step 1.
+
+         Otherwise, copy all RRs which match QTYPE into the answer
+         section and go to step 6.
+
+      b. If a match would take us out of the authoritative data, we have
+         a referral.  This happens when we encounter a node with NS RRs
+         marking cuts along the bottom of a zone.
+
+         Copy the NS RRs for the subzone into the authority section of
+         the reply.  Put whatever addresses are available into the
+         additional section, using glue RRs if the addresses are not
+         available from authoritative data or the cache.  Go to step 4.
+
+      c. If at some label, a match is impossible (i.e., the
+         corresponding label does not exist), look to see whether the
+         last label matched has a BNAME record.
+
+
+         If a BNAME record exists at that point, copy that record into
+         the answer section.  If substitution of its <target> for its
+         <owner> in QNAME would overflow the legal size for a <domain-
+         name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
+         perform the substitution and continue.  The server SHOULD
+         synthesize a corresponding CNAME record as described above and
+         include it in the answer section.  Go back to step 1.
+
+         If there was no BNAME record, look to see if the "*" label
+         exists.
+
+         If the "*" label does not exist, check whether the name we are
+         looking for is the original QNAME in the query or a name we
+         have followed due to a CNAME.  If the name is original, set an
+         authoritative name error in the response and exit.  Otherwise
+         just exit.
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 7]
+
+Internet-Draft                    bname                      August 2010
+
+
+
+         If the "*" label does exist, match RRs at that node against
+         QTYPE.  If any match, copy them into the answer section, but
+         set the owner of the RR to be QNAME, and not the node with the
+         "*" label.  Go to step 6.
+
+
+   4. Start matching down in the cache.  If QNAME is found in the cache,
+      copy all RRs attached to it that match QTYPE into the answer
+      section.  If QNAME is not found in the cache but a BNAME record is
+      present at QNAME, copy that BNAME record into the
+      answer section.  If there was no delegation from authoritative
+      data, look for the best one from the cache, and put it in the
+      authority section.  Go to step 6.
+
+   5. Use the local resolver or a copy of its algorithm (see resolver
+      section of this memo) to answer the query.  Store the results,
+      including any intermediate CNAMEs and BNAMEs, in the answer
+      section of the response.
+
+   6. Using local data only, attempt to add other RRs which may be
+      useful to the additional section of the query.  Exit.
+
+
+
+   Note that there will be at most one ancestor with a BNAME as
+   described in step 4 unless some zone's data is in violation of the
+   no-descendants limitation in section 3.  An implementation might take
+   advantage of this limitation by stopping the search of step 3c or
+   step 4 when a BNAME record is encountered.
+
+
+4.2.  Processing by Resolvers
+
+   A resolver or a server providing recursive service must be modified
+   to treat a BNAME as somewhat analogous to a CNAME.  The resolver
+   algorithm of [RFC1034] section 5.3.3 is modified to renumber step 4.d
+   as 4.e and insert a new 4.d.  The complete algorithm becomes:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 8]
+
+Internet-Draft                    bname                      August 2010
+
+
+   1. See if the answer is in local information, and if so return it to
+      the client.
+
+   2. Find the best servers to ask.
+
+   3. Send them queries until one returns a response.
+
+   4. Analyze the response, either:
+
+      a. if the response answers the question or contains a name error,
+         cache the data as well as returning it back to the client.
+
+      b. if the response contains a better delegation to other servers,
+         cache the delegation information, and go to step 2.
+
+      c. if the response shows a CNAME and that is not the answer
+         itself, cache the CNAME, change the SNAME to the canonical name
+         in the CNAME RR and go to step 1.
+
+      d. if the response shows a BNAME and that is not the answer
+         itself, cache the BNAME.  If substitution of the BNAME's
+         <target> for its <owner> in the SNAME would overflow the legal
+         size for a <domain-name>, return an implementation-dependent
+         error to the application; otherwise perform the substitution
+         and go to step 1.
+
+      e. if the response shows a server failure or other bizarre
+         contents, delete the server from the SLIST and go back to step
+         3.
+
+
+   A resolver or recursive server which understands BNAME records but
+   sends non-extended queries MUST augment step 4.c by deleting from the
+   reply any CNAME records which have an <owner> which is a subdomain of
+   the <owner> of any BNAME record in the response.
+
+
+5.  BNAME in DNSSEC
+
+5.1.  BNAME validating
+
+   With the deployment of DNSSEC, more and more servers and resolvers
+   will support DNSSEC.  In order to make BNAME valid in DNSSEC
+   verification, the DNSSEC enabled resolvers and servers MUST support
+   BNAME.  The synthesized CNAME in the answer section for the BNAME
+   will never be signed if there has one.
+
+   If the owner name of the bname is the suffix of the name queryed but
+
+
+
+Yao, et al.             Expires February 12, 2011               [Page 9]
+
+Internet-Draft                    bname                      August 2010
+
+
+   different, DNSSEC validators MUST understand BNAME, verify the BNAME
+   and then checking that the CNAME was properly synthesized in order to
+   verify the synthesized CNAME.
+
+   If the owner name of the bname is same with the name queryed, DNSSEC
+   validators MUST understand BNAME and verify the BNAME.  The BNAME
+   enabled resolver (validator) should do somewhat analogous to a CNAME
+   for further query.
+
+   In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
+   map SHOULD be checked to see that there was no BNAME that could have
+   been applied.  If the BNAME bit in the type bit map is set and the
+   query type is not BNAME, then BNAME substitution should have been
+   done.
+
+5.2.  BNAME alias algorithm identifiers
+
+   In order to prevent BNAME-unaware resolvers from attempting to
+   validate responses from BNAME-signed zones, this specification
+   allocates two new DNSKEY algorithm identifiers.  Algorithm Y, DSA-
+   BNAME-SHA1 is an alias for algorithm 3, DSA.  Algorithm Z, RSASHA1-
+   BNAME-SHA1 is an alias for algorithm 5, RSASHA1.  These are not new
+   algorithms, they are additional identifiers for the existing
+   algorithms.  Zones signed according to this specification MUST only
+   use these algorithm identifiers for their DNSKEY RRs.  The BNAME-
+   unaware resolvers will not know these new identifiers and treat
+   responses from the BNAME signed zone as insecure, otherwise the bname
+   RR will be regarded as bogus if there is no such a mechanism.  These
+   algorithm identifiers are used with the BNAME hash algorithm SHA1.
+   Using other BNAME hash algorithms requires allocation of a new alias.
+   Validating resolvers which follow the BNAME specification MUST
+   recognize the new alias algorithm identifier.
+
+
+6.  IANA Considerations
+
+   IANA is requested to assign the number to XX.  This document updates
+   the IANA registry "DNS SECURITY ALGORITHM NUMBERS".  IANA is
+   requested to assign the number to Y and Z.
+
+   [[anchor14: Note in draft: before this document goes to WG Last call,
+   it is better that we list all DNSSEC algorithms that need to be
+   aliased to reflect compatibility with this extension.]]
+
+
+7.  Security Considerations
+
+   Both ASCII domain name labels and non-ASCII ones have some aliases.
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 10]
+
+Internet-Draft                    bname                      August 2010
+
+
+   We can bundle the domain name labels and their aliases through BNAME
+   in the DNS resolutions.  The name labels and their aliases in the
+   particular languages are only known by those who know these
+   languages.  Those labels may be regarded as different ones by those
+   who don't know those languages.  Those who do not know the aliases
+   should only use the familar ones.  The applications will not know the
+   aliases unless they are properly configured.
+
+
+8.  Acknowledgements
+
+   Because the BNAME is very similar to DNAME, the authors learn a lot
+   from [RFC2672].  Many ideas are from the discussion in the DNSOP and
+   DNSEXT mailling list.  Thanks a lot to all in the list.  Many
+   important comments and suggestions are contributed by many members of
+   the DNSEXT and DNSOP WGs.  The authors especially thanks the
+   following ones:Niall O'Reilly, Glen Zorn, Mark Andrews, George
+   Barwood,Olafur Gudmundsson, Sun Guonian and Hanfeng for improving
+   this document.
+
+
+9.  Change History
+
+   [[anchor17: RFC Editor: Please remove this section.]]
+
+9.1.  draft-yao-dnsext-bname: Version 00
+
+   o  Bundle DNS Name Redirection
+
+9.2.  draft-yao-dnsext-bname: Version 01
+
+   o  Improve the algorithm
+   o  Improve the text
+
+9.3.  draft-yao-dnsext-bname: Version 02
+
+   o  Add the DNSSEC discussion
+   o  Improve the text
+
+9.4.  draft-yao-dnsext-bname: Version 03
+
+   o  Update the DNSSEC discussion
+   o  Update the IANA consideration
+
+
+10.  References
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 11]
+
+Internet-Draft                    bname                      August 2010
+
+
+10.1.  Normative References
+
+   [ASCII]    American National Standards Institute (formerly United
+              States of America Standards Institute), "USA Code for
+              Information Interchange", ANSI X3.4-1968, 1968.
+
+   [EDNS0]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
+              RFC 2672, August 1999.
+
+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
+              "Internationalizing Domain Names in Applications (IDNA)",
+              RFC 3490, March 2003.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", RFC 3629, November 2003.
+
+   [RFC3743]  Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
+              Engineering Team (JET) Guidelines for Internationalized
+              Domain Names (IDN) Registration and Administration for
+              Chinese, Japanese, and Korean", RFC 3743, April 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 12]
+
+Internet-Draft                    bname                      August 2010
+
+
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+10.2.  Informative References
+
+   [RFC2672bis]
+              Rose, S. and W. Wijngaards, "Update to DNAME Redirection
+              in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname-
+              17.txt, 6 2009.
+
+
+Authors' Addresses
+
+   Jiankang YAO
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+
+   Phone: +86 10 58813007
+   Email: yaojk@cnnic.cn
+
+
+   Xiaodong LEE
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+
+   Phone: +86 10 58813020
+   Email: lee@cnnic.cn
+
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA
+
+   Phone: +1 650 779 7001
+   Email: vixie@isc.org
+
+
+
+
+
+Yao, et al.             Expires February 12, 2011              [Page 13]
+
+
+

doc/private/SRCID

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

doc/rfc/index

@@ -138,3 +138,6 @@
 5625:	DNS Proxy Implementation Guidelines
 5702:   Use of SHA-2 Algorithms with RSA in
          DNSKEY and RRSIG Resource Records for DNSSEC
+5933:	Use of GOST Signature Algorithms in DNSKEY
+         and RRSIG Resource Records for DNSSEC
+

doc/rfc/rfc5933.txt

@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                  V. Dolmatov, Ed.
+Request for Comments: 5933                                   A. Chuprina
+Category: Standards Track                                     I. Ustinov
+ISSN: 2070-1721                                           Cryptocom Ltd.
+                                                               July 2010
+
+
+               Use of GOST Signature Algorithms in DNSKEY
+                 and RRSIG Resource Records for DNSSEC
+
+Abstract
+
+   This document describes how to produce digital signatures and hash
+   functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms
+   for DNSKEY, RRSIG, and DS resource records, for use in the Domain
+   Name System Security Extensions (DNSSEC).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5933.
+
+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
+   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.
+
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 1]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
+     2.1.  Using a Public Key with Existing Cryptographic
+           Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 4
+   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
+     3.1.  RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . 5
+   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
+     4.1.  DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 5
+   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 6
+     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 6
+     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 6
+   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 6
+     6.1.  Support for GOST Signatures . . . . . . . . . . . . . . . . 6
+     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 6
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
+     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical distributed
+   database for Internet Naming.  The DNS has been extended to use
+   cryptographic keys and digital signatures for the verification of the
+   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
+   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
+   Extensions, called DNSSEC.
+
+   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
+   and specifies a list of cryptographic algorithms to use.  This
+   document extends that list with the signature and hash algorithms
+   GOST R 34.10-2001 ([GOST3410], [RFC5832]) and GOST R 34.11-94
+   ([GOST3411], [RFC5831]), and specifies how to store DNSKEY data and
+   how to produce RRSIG resource records with these algorithms.
+
+   Familiarity with DNSSEC and with GOST signature and hash algorithms
+   is assumed in this document.
+
+   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 [RFC5832], GOST R 34.11-94 [RFC5831], and
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 2]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+   GOST 28147-89 [RFC5830].  Since GOST 28147-89 is not used in DNSSEC,
+   "GOST" will only refer to GOST R 34.10-2001 and GOST R 34.11-94 in
+   this document.
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  DNSKEY Resource Records
+
+   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
+
+   GOST R 34.10-2001 public keys are stored with the algorithm
+   number 12.
+
+   The wire format of the public key is compatible with RFC 4491
+   [RFC4491]:
+
+   According to [GOST3410] and [RFC5832], a public key is a point on the
+   elliptic curve Q = (x,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.
+
+   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
+   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
+
+2.1.  Using a Public Key with Existing Cryptographic Libraries
+
+   At the time of this writing, existing GOST-aware cryptographic
+   libraries are capable of reading GOST public keys via a generic X509
+   API if the key is encoded according to RFC 4491 [RFC4491],
+   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 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
+      0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 3]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+2.2.  GOST DNSKEY RR Example
+
+   Given a private key with the following value (the value of the
+   GostAsn1 field is split here into two lines to simplify reading; in
+   the private key file, it must be in one line):
+
+      Private-key-format: v1.2
+      Algorithm: 12 (ECC-GOST)
+      GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQg/9M
+                iXtXKg9FDXDN/R9CmVhJDyuzRAIgh4tPwCu4NHIs=
+
+   The following DNSKEY RR stores a DNS zone key for example.net:
+
+      example.net. 86400 IN DNSKEY 256 3 12 (
+                                   aRS/DcPWGQj2wVJydT8EcAVoC0kXn5pDVm2I
+                                   MvDDPXeD32dsSKcmq8KNVzigjL4OXZTV+t/6
+                                   w4X1gpNrZiC01g==
+                                   ) ; key id = 59732
+
+3.  RRSIG Resource Records
+
+   The value of the signature field in the RRSIG RR follows RFC 4490
+   [RFC4490] and is calculated as follows.  The values for the RDATA
+   fields that precede the signature data are specified in RFC 4034
+   [RFC4034].
+
+   hash = GOSTR3411(data)
+
+   where "data" is the wire format data of the resource record set that
+   is signed, as specified in RFC 4034 [RFC4034].
+
+   The hash MUST be calculated with GOST R 34.11-94 parameters
+   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+   The signature is calculated from the hash according to the
+   GOST R 34.10-2001 standard, and its wire format is compatible with
+   RFC 4490 [RFC4490].
+
+   Quoting RFC 4490:
+
+   "The signature algorithm GOST R 34.10-2001 generates a digital
+   signature in the form of two 256-bit numbers, r and s.  Its octet
+   string representation consists of 64 octets, where the first
+   32 octets contain the big-endian representation of s and the second
+   32 octets contain the big-endian representation of r".
+
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 4]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+3.1.  RRSIG RR Example
+
+   With the private key from Section 2.2, sign the following RRSet,
+   consisting of one A record:
+
+      www.example.net. 3600 IN A 192.0.2.1
+
+   Setting the inception date to 2000-01-01 00:00:00 UTC and the
+   expiration date to 2030-01-01 00:00:00 UTC, the following signature
+   RR will be valid:
+
+     www.example.net. 3600 IN RRSIG A 12 3 3600 20300101000000 (
+                                    20000101000000 59732 example.net.
+                                    7vzzz6iLOmvtjs5FjVjSHT8XnRKFY15ki6Kp
+                                    kNPkUnS8iIns0Kv4APT+D9ibmHhGri6Sfbyy
+                                    zi67+wBbbW/jrA== )
+
+   Note: The ECC-GOST signature algorithm uses random data, so the
+   actual computed signature value will differ between signature
+   calculations.
+
+4.  DS Resource Records
+
+   The GOST R 34.11-94 digest algorithm is denoted in DS RRs by the
+   digest type 3.  The wire format of a digest value is compatible with
+   RFC 4490 [RFC4490], that is, the digest is in little-endian
+   representation.
+
+   The digest MUST always be calculated with GOST R 34.11-94 parameters
+   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+4.1.  DS RR Example
+
+   For Key Signing Key (KSK):
+
+      example.net. 86400   DNSKEY  257 3 12 (
+                                   LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO
+                                   gEYqYS/rlh2Mf+BRAY3QHPbwoPh2fkDKBroF
+                                   SRGR7ZYcx+YIQw==
+                                   ) ; key id = 40692
+
+   The DS RR will be
+
+      example.net. 3600 IN DS 40692 12 3 (
+                22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B
+                2071398F )
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 5]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+5.  Deployment Considerations
+
+5.1.  Key Sizes
+
+   According to RFC 4357 [RFC4357], the key size of GOST public keys
+   MUST be 512 bits.
+
+5.2.  Signature Sizes
+
+   According to the GOST R 34.10-2001 digital signature algorithm
+   specification ([GOST3410], [RFC5832]), the size of a GOST signature
+   is 512 bits.
+
+5.3.  Digest Sizes
+
+   According to GOST R 34.11-94 ([GOST3411], [RFC5831]), the size of a
+   GOST digest is 256 bits.
+
+6.  Implementation Considerations
+
+6.1.  Support for GOST Signatures
+
+   DNSSEC-aware implementations MAY be able to support RRSIG and DNSKEY
+   resource records created with the GOST algorithms as defined in this
+   document.
+
+6.2.  Support for NSEC3 Denial of Existence
+
+   Any DNSSEC-GOST implementation MUST support both NSEC [RFC4035] and
+   NSEC3 [RFC5155].
+
+7.  Security Considerations
+
+   Currently, the cryptographic resistance of the GOST R 34.10-2001
+   digital signature algorithm is estimated as 2**128 operations of
+   multiple elliptic curve point computations on prime modulus of order
+   2**256.
+
+   Currently, the cryptographic resistance of the GOST R 34.11-94 hash
+   algorithm is estimated as 2**128 operations of computations of a step
+   hash function.  (There is a known method to reduce this estimate to
+   2**105 operations, but it demands padding the colliding message with
+   1024 random bit blocks each of 256-bit length; thus, it cannot be
+   used in any practical implementation).
+
+
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 6]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+8.  IANA Considerations
+
+   This document updates the IANA registry "DNS Security Algorithm
+   Numbers" [RFC4034].  The following entries have been added to the
+   registry:
+
+                                      Zone    Trans.
+    Value  Algorithm         Mnemonic Signing Sec.  References   Status
+     12    GOST R 34.10-2001 ECC-GOST     Y   *     RFC 5933    OPTIONAL
+
+   This document updates the RFC 4034 Digest Types assignment
+   ([RFC4034], Section A.2) by adding the value and status for the
+   GOST R 34.11-94 algorithm:
+
+      Value   Algorithm        Status
+        3    GOST R 34.11-94  OPTIONAL
+
+9.  Acknowledgments
+
+   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
+   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
+   and RFC 4357 [RFC4357] for consistency.  The authors of and
+   contributors to these documents are gratefully acknowledged for their
+   hard work.
+
+   The following people provided additional feedback, text, and valuable
+   assistance: Dmitry Burkov, Jaap Akkerhuis, Olafur Gundmundsson,
+   Jelte Jansen, and Wouter Wijngaards.
+
+10.  References
+
+10.1.  Normative References
+
+   [GOST3410]  "Information technology.  Cryptographic data security.
+               Signature and verification processes of [electronic]
+               digital signature.", GOST R 34.10-2001, Gosudarstvennyi
+               Standard of Russian Federation, Government Committee of
+               Russia for Standards, 2001. (In Russian).
+
+   [GOST3411]  "Information technology.  Cryptographic data security.
+               Hashing function.", GOST R 34.11-94, Gosudarstvennyi
+               Standard of Russian Federation, Government Committee of
+               Russia for Standards, 1994. (In Russian).
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 7]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+   [RFC3110]   Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+               Domain Name System (DNS)", RFC 3110, May 2001.
+
+   [RFC4033]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "DNS Security Introduction and Requirements",
+               RFC 4033, March 2005.
+
+   [RFC4034]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "Resource Records for the DNS Security Extensions",
+               RFC 4034, March 2005.
+
+   [RFC4035]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "Protocol Modifications for the DNS Security
+               Extensions", RFC 4035, March 2005.
+
+   [RFC4357]   Popov, V., Kurepkin, I., and S. Leontiev, "Additional
+               Cryptographic Algorithms for Use with GOST 28147-89,
+               GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+               Algorithms", RFC 4357, January 2006.
+
+   [RFC4490]   Leontiev, S., Ed. and G. Chudov, Ed., "Using the
+               GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and
+               GOST R 34.10-2001 Algorithms with Cryptographic Message
+               Syntax (CMS)", RFC 4490, May 2006.
+
+   [RFC4491]   Leontiev, S., Ed. and D. Shefanovski, Ed., "Using the
+               GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+               Algorithms with the Internet X.509 Public Key
+               Infrastructure Certificate and CRL Profile", RFC 4491,
+               May 2006.
+
+   [RFC5155]   Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+               Security (DNSSEC) Hashed Authenticated Denial of
+               Existence", RFC 5155, March 2008.
+
+10.2.  Informative References
+
+   [RFC4509]   Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+               (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC5830]   Dolmatov, V., Ed., "GOST 28147-89: Encryption,
+               Decryption, and Message Authentication Code (MAC)
+               Algorithms", RFC 5830, March 2010.
+
+   [RFC5831]   Dolmatov, V., Ed., "GOST R 34.11-94: Hash Function
+               Algorithm", RFC 5831, March 2010.
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 8]
+
+RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
+
+
+   [RFC5832]   Dolmatov, V., Ed., "GOST R 34.10-2001: Digital Signature
+               Algorithm", RFC 5832, March 2010.
+
+Authors' Addresses
+
+   Vasily Dolmatov (editor)
+   Cryptocom Ltd.
+   14/2, Kedrova St.
+   Moscow,   117218
+   Russian Federation
+
+   Phone: +7 499 124 6226
+   EMail: dol@cryptocom.ru
+
+
+   Artem Chuprina
+   Cryptocom Ltd.
+   14/2, Kedrova St.
+   Moscow,   117218
+   Russian Federation
+
+   Phone: +7 499 124 6226
+   EMail: ran@cryptocom.ru
+
+
+   Igor Ustinov
+   Cryptocom Ltd.
+   14/2, Kedrova St.
+   Moscow,   117218
+   Russian Federation
+
+   Phone: +7 499 124 6226
+   EMail: igus@cryptocom.ru
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dolmatov, et al.             Standards Track                    [Page 9]
+

lib/dns/api

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

lib/dns/include/dns/db.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) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: db.h,v 1.76.18.14 2009/01/19 00:36:28 marka Exp $ */
+/* $Id: db.h,v 1.76.18.16 2010/11/17 23:45:12 tbox Exp $ */
 
 #ifndef DNS_DB_H
 #define DNS_DB_H 1
@@ -184,13 +184,15 @@ struct dns_db {
 /*%
  * Options that can be specified for dns_db_find().
  */
-#define DNS_DBFIND_GLUEOK		0x01
-#define DNS_DBFIND_VALIDATEGLUE		0x02
-#define DNS_DBFIND_NOWILD		0x04
-#define DNS_DBFIND_PENDINGOK		0x08
-#define DNS_DBFIND_NOEXACT		0x10
-#define DNS_DBFIND_FORCENSEC		0x20
-#define DNS_DBFIND_COVERINGNSEC		0x40
+#define DNS_DBFIND_GLUEOK		0x0001
+#define DNS_DBFIND_VALIDATEGLUE		0x0002
+#define DNS_DBFIND_NOWILD		0x0004
+#define DNS_DBFIND_PENDINGOK		0x0008
+#define DNS_DBFIND_NOEXACT		0x0010
+#define DNS_DBFIND_FORCENSEC		0x0020
+#define DNS_DBFIND_COVERINGNSEC		0x0040
+#define DNS_DBFIND_FORCENSEC3		0x0080
+#define DNS_DBFIND_ADDITIONALOK		0x0100
 /*@}*/
 
 /*@{*/
@@ -649,6 +651,10 @@ dns_db_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
  *	For cache databases, glue is any rdataset with a trust of
  *	dns_trust_glue.
  *
+ * \li	If 'options' does not have #DNS_DBFIND_ADDITIONALOK set, then no
+ *	additional records will be returned.  Only caches can have
+ *	rdataset with trust dns_trust_additional.
+ *
  * \li	If 'options' does not have #DNS_DBFIND_PENDINGOK set, then no
  *	pending data will be returned.  This option is only meaningful for
  *	cache databases.

lib/dns/include/dns/ncache.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) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ncache.h,v 1.17.18.2 2005/04/29 00:16:16 marka Exp $ */
+/* $Id: ncache.h,v 1.17.18.4 2010/06/04 23:46:02 tbox Exp $ */
 
 #ifndef DNS_NCACHE_H
 #define DNS_NCACHE_H 1
@@ -63,6 +63,11 @@ isc_result_t
 dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	       dns_rdatatype_t covers, isc_stdtime_t now, dns_ttl_t maxttl,
 	       dns_rdataset_t *addedrdataset);
+isc_result_t
+dns_ncache_addoptout(dns_message_t *message, dns_db_t *cache,
+		     dns_dbnode_t *node, dns_rdatatype_t covers,
+		     isc_stdtime_t now, dns_ttl_t maxttl,
+		     isc_boolean_t optout, dns_rdataset_t *addedrdataset);
 /*%<
  * Convert the authority data from 'message' into a negative cache
  * rdataset, and store it in 'cache' at 'node' with a TTL limited to
@@ -71,6 +76,8 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
  * The 'covers' argument is the RR type whose nonexistence we are caching,
  * or dns_rdatatype_any when caching a NXDOMAIN response.
  *
+ * 'optout' indicates a DNS_RDATASETATTR_OPTOUT should be set.
+ *
  * Note:
  *\li	If 'addedrdataset' is not NULL, then it will be attached to the added
  *	rdataset.  See dns_db_addrdataset() for more details.
@@ -154,6 +161,26 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
  *
  */
 
+isc_result_t
+dns_ncache_getsigrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
+			  dns_rdatatype_t covers, dns_rdataset_t *rdataset);
+/*%<
+ * Similar to dns_ncache_getrdataset() but get the rrsig that matches.
+ */
+
+void
+dns_ncache_current(dns_rdataset_t *ncacherdataset, dns_name_t *found,
+		   dns_rdataset_t *rdataset);
+
+/*%<
+ * Extract the current rdataset and name from a ncache entry.
+ *
+ * Requires:
+ * \li	'ncacherdataset' to be valid and to be a negative cache entry
+ * \li	'found' to be valid.
+ * \li	'rdataset' to be unassociated.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_NCACHE_H */

lib/dns/include/dns/rdataset.h

@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataset.h,v 1.51.18.11 2010/02/26 23:46:37 tbox Exp $ */
+/* $Id: rdataset.h,v 1.51.18.11.10.1 2011/05/26 23:56:27 each Exp $ */
 
 #ifndef DNS_RDATASET_H
 #define DNS_RDATASET_H 1
@@ -608,6 +608,12 @@ dns_rdataset_expire(dns_rdataset_t *rdataset);
  * Mark the rdataset to be expired in the backing database.
  */
 
+const char *
+dns_trust_totext(dns_trust_t trust);
+/*
+ *  * Display trust in textual form.
+ *   */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RDATASET_H */

lib/dns/include/dns/types.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) 1998-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: types.h,v 1.109.18.15 2009/11/25 04:50:25 marka Exp $ */
+/* $Id: types.h,v 1.109.18.17 2010/06/04 23:46:02 tbox Exp $ */
 
 #ifndef DNS_TYPES_H
 #define DNS_TYPES_H 1
@@ -285,6 +285,7 @@ enum {
 #define DNS_TRUST_PENDING(x)		((x) == dns_trust_pending_answer || \
 					 (x) == dns_trust_pending_additional)
 #define DNS_TRUST_GLUE(x)		((x) == dns_trust_glue)
+#define DNS_TRUST_ANSWER(x)		((x) == dns_trust_answer)
 
 
 /*%

lib/dns/ncache.c

@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ncache.c,v 1.36.18.5 2010/02/26 23:46:36 tbox Exp $ */
+/* $Id: ncache.c,v 1.36.18.8.10.1 2011/05/26 23:56:27 each Exp $ */
 
 /*! \file */
 
@@ -30,6 +30,9 @@
 #include <dns/rdata.h>
 #include <dns/rdatalist.h>
 #include <dns/rdataset.h>
+#include <dns/rdatastruct.h>
+
+#define DNS_NCACHE_RDATA 20U
 
 /*
  * The format of an ncache rdata is a sequence of one or more records of
@@ -37,6 +40,7 @@
  *
  *	owner name
  *	type
+ *	trust
  *	rdata count
  *		rdata length			These two occur 'rdata count'
  *		rdata				times.
@@ -100,10 +104,11 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	dns_name_t *name;
 	dns_ttl_t ttl;
 	dns_trust_t trust;
-	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdata_t rdata[DNS_NCACHE_RDATA];
 	dns_rdataset_t ncrdataset;
 	dns_rdatalist_t ncrdatalist;
 	unsigned char data[4096];
+	unsigned int next = 0;
 
 	/*
 	 * Convert the authority data from 'message' into a negative cache
@@ -118,7 +123,17 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	 */
 
 	/*
-	 * First, build an ncache rdata in buffer.
+	 * Initialize the list.
+	 */
+	ncrdatalist.rdclass = dns_db_class(cache);
+	ncrdatalist.type = 0;
+	ncrdatalist.covers = covers;
+	ncrdatalist.ttl = maxttl;
+	ISC_LIST_INIT(ncrdatalist.rdata);
+	ISC_LINK_INIT(&ncrdatalist, link);
+
+	/*
+	 * Build an ncache rdatas into buffer.
 	 */
 	ttl = maxttl;
 	trust = 0xffff;
@@ -160,10 +175,12 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 					 */
 					isc_buffer_availableregion(&buffer,
 								   &r);
-					if (r.length < 2)
+					if (r.length < 3)
 						return (ISC_R_NOSPACE);
 					isc_buffer_putuint16(&buffer,
 							     rdataset->type);
+					isc_buffer_putuint8(&buffer,
+							     rdataset->trust);
 					/*
 					 * Copy the rdataset into the buffer.
 					 */
@@ -171,6 +188,21 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 							       &buffer);
 					if (result != ISC_R_SUCCESS)
 						return (result);
+
+					if (next >= DNS_NCACHE_RDATA)
+						return (ISC_R_NOSPACE);
+					dns_rdata_init(&rdata[next]);
+					isc_buffer_remainingregion(&buffer, &r);
+					rdata[next].data = r.base;
+					rdata[next].length = r.length;
+					rdata[next].rdclass =
+						ncrdatalist.rdclass;
+					rdata[next].type = 0;
+					rdata[next].flags = 0;
+					ISC_LIST_APPEND(ncrdatalist.rdata,
+							&rdata[next], link);
+					isc_buffer_forward(&buffer, r.length);
+					next++;
 				}
 			}
 		}
@@ -205,10 +237,9 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 		 * Copy the type and a zero rdata count to the buffer.
 		 */
 		isc_buffer_availableregion(&buffer, &r);
-		if (r.length < 4)
+		if (r.length < 5)
 			return (ISC_R_NOSPACE);
-		isc_buffer_putuint16(&buffer, 0);
-		isc_buffer_putuint16(&buffer, 0);
+		isc_buffer_putuint16(&buffer, 0);	/* type */
 		/*
 		 * RFC2308, section 5, says that negative answers without
 		 * SOAs should not be cached.
@@ -226,27 +257,27 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 			trust = dns_trust_authauthority;
 		} else
 			trust = dns_trust_additional;
+		isc_buffer_putuint8(&buffer, trust);	/* trust */
+		isc_buffer_putuint16(&buffer, 0);	/* count */
+
+		/*
+		 * Now add it to the cache.
+		 */
+		if (next >= DNS_NCACHE_RDATA)
+			return (ISC_R_NOSPACE);
+		dns_rdata_init(&rdata[next]);
+		isc_buffer_remainingregion(&buffer, &r);
+		rdata[next].data = r.base;
+		rdata[next].length = r.length;
+		rdata[next].rdclass = ncrdatalist.rdclass;
+		rdata[next].type = 0;
+		rdata[next].flags = 0;
+		ISC_LIST_APPEND(ncrdatalist.rdata, &rdata[next], link);
 	}
 
-	/*
-	 * Now add it to the cache.
-	 */
 	INSIST(trust != 0xffff);
-	isc_buffer_usedregion(&buffer, &r);
-	rdata.data = r.base;
-	rdata.length = r.length;
-	rdata.rdclass = dns_db_class(cache);
-	rdata.type = 0;
-	rdata.flags = 0;
 
-	ncrdatalist.rdclass = rdata.rdclass;
-	ncrdatalist.type = 0;
-	ncrdatalist.covers = covers;
 	ncrdatalist.ttl = ttl;
-	ISC_LIST_INIT(ncrdatalist.rdata);
-	ISC_LINK_INIT(&ncrdatalist, link);
-
-	ISC_LIST_APPEND(ncrdatalist.rdata, &rdata, link);
 
 	dns_rdataset_init(&ncrdataset);
 	RUNTIME_CHECK(dns_rdatalist_tordataset(&ncrdatalist, &ncrdataset)
@@ -281,18 +312,14 @@ dns_ncache_towire(dns_rdataset_t *rdataset, dns_compress_t *cctx,
 	REQUIRE(rdataset != NULL);
 	REQUIRE(rdataset->type == 0);
 
-	result = dns_rdataset_first(rdataset);
-	if (result != ISC_R_SUCCESS)
-		return (result);
-	dns_rdataset_current(rdataset, &rdata);
-	INSIST(dns_rdataset_next(rdataset) == ISC_R_NOMORE);
-	isc_buffer_init(&source, rdata.data, rdata.length);
-	isc_buffer_add(&source, rdata.length);
-
 	savedbuffer = *target;
-
 	count = 0;
-	do {
+
+	result = dns_rdataset_first(rdataset);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdataset_current(rdataset, &rdata);
+		isc_buffer_init(&source, rdata.data, rdata.length);
+		isc_buffer_add(&source, rdata.length);
 		dns_name_init(&name, NULL);
 		isc_buffer_remainingregion(&source, &remaining);
 		dns_name_fromregion(&name, &remaining);
@@ -300,8 +327,9 @@ dns_ncache_towire(dns_rdataset_t *rdataset, dns_compress_t *cctx,
 		isc_buffer_forward(&source, name.length);
 		remaining.length -= name.length;
 
-		INSIST(remaining.length >= 4);
+		INSIST(remaining.length >= 5);
 		type = isc_buffer_getuint16(&source);
+		isc_buffer_forward(&source, 1);
 		rcount = isc_buffer_getuint16(&source);
 
 		for (i = 0; i < rcount; i++) {
@@ -370,8 +398,12 @@ dns_ncache_towire(dns_rdataset_t *rdataset, dns_compress_t *cctx,
 
 			count++;
 		}
-		isc_buffer_remainingregion(&source, &remaining);
-	} while (remaining.length > 0);
+		INSIST(isc_buffer_remaininglength(&source) == 0);
+		result = dns_rdataset_next(rdataset);
+		dns_rdata_reset(&rdata);
+	}
+	if (result != ISC_R_NOMORE)
+		goto rollback;
 
 	*countp = count;
 
@@ -467,6 +499,13 @@ rdataset_count(dns_rdataset_t *rdataset) {
 	return (count);
 }
 
+static void
+rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust) {
+	unsigned char *raw = rdataset->private3;
+
+	raw[-1] = trust;
+}
+
 static dns_rdatasetmethods_t rdataset_methods = {
 	rdataset_disassociate,
 	rdataset_first,
@@ -479,8 +518,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	NULL,
 	NULL,
 	NULL,
+	rdataset_settrust,
 	NULL,
-	NULL
 };
 
 isc_result_t
@@ -493,8 +532,8 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 	isc_buffer_t source;
 	dns_name_t tname;
 	dns_rdatatype_t ttype;
-	unsigned int i, rcount;
-	isc_uint16_t length;
+	dns_trust_t trust = dns_trust_none;
+	dns_rdataset_t clone;
 
 	REQUIRE(ncacherdataset != NULL);
 	REQUIRE(ncacherdataset->type == 0);
@@ -502,15 +541,13 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 	REQUIRE(!dns_rdataset_isassociated(rdataset));
 	REQUIRE(type != dns_rdatatype_rrsig);
 
-	result = dns_rdataset_first(ncacherdataset);
-	if (result != ISC_R_SUCCESS)
-		return (result);
-	dns_rdataset_current(ncacherdataset, &rdata);
-	INSIST(dns_rdataset_next(ncacherdataset) == ISC_R_NOMORE);
-	isc_buffer_init(&source, rdata.data, rdata.length);
-	isc_buffer_add(&source, rdata.length);
-
-	do {
+	dns_rdataset_init(&clone);
+	dns_rdataset_clone(ncacherdataset, &clone);
+	result = dns_rdataset_first(&clone);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdataset_current(&clone, &rdata);
+		isc_buffer_init(&source, rdata.data, rdata.length);
+		isc_buffer_add(&source, rdata.length);
 		dns_name_init(&tname, NULL);
 		isc_buffer_remainingregion(&source, &remaining);
 		dns_name_fromregion(&tname, &remaining);
@@ -518,35 +555,32 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 		isc_buffer_forward(&source, tname.length);
 		remaining.length -= tname.length;
 
-		INSIST(remaining.length >= 4);
+		INSIST(remaining.length >= 3);
 		ttype = isc_buffer_getuint16(&source);
 
 		if (ttype == type && dns_name_equal(&tname, name)) {
+			trust = isc_buffer_getuint8(&source);
+			INSIST(trust <= dns_trust_ultimate);
 			isc_buffer_remainingregion(&source, &remaining);
 			break;
 		}
-
-		rcount = isc_buffer_getuint16(&source);
-		for (i = 0; i < rcount; i++) {
-			isc_buffer_remainingregion(&source, &remaining);
-			INSIST(remaining.length >= 2);
-			length = isc_buffer_getuint16(&source);
-			isc_buffer_remainingregion(&source, &remaining);
-			INSIST(remaining.length >= length);
-			isc_buffer_forward(&source, length);
-		}
-		isc_buffer_remainingregion(&source, &remaining);
-	} while (remaining.length > 0);
-
-	if (remaining.length == 0)
+		result = dns_rdataset_next(&clone);
+		dns_rdata_reset(&rdata);
+	}
+	dns_rdataset_disassociate(&clone);
+	if (result == ISC_R_NOMORE)
 		return (ISC_R_NOTFOUND);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	INSIST(remaining.length != 0);
 
 	rdataset->methods = &rdataset_methods;
 	rdataset->rdclass = ncacherdataset->rdclass;
 	rdataset->type = type;
 	rdataset->covers = 0;
 	rdataset->ttl = ncacherdataset->ttl;
-	rdataset->trust = ncacherdataset->trust;
+	rdataset->trust = trust;
 	rdataset->private1 = NULL;
 	rdataset->private2 = NULL;
 
@@ -557,5 +591,179 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 	 */
 	rdataset->privateuint4 = 0;
 	rdataset->private5 = NULL;
+	rdataset->private6 = NULL;
 	return (ISC_R_SUCCESS);
 }
+
+isc_result_t
+dns_ncache_getsigrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
+			  dns_rdatatype_t covers, dns_rdataset_t *rdataset)
+{
+	dns_name_t tname;
+	dns_rdata_rrsig_t rrsig;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t clone;
+	dns_rdatatype_t type;
+	dns_trust_t trust = dns_trust_none;
+	isc_buffer_t source;
+	isc_region_t remaining, sigregion;
+	isc_result_t result;
+	unsigned char *raw;
+	unsigned int count;
+
+	REQUIRE(ncacherdataset != NULL);
+	REQUIRE(ncacherdataset->type == 0);
+	REQUIRE(name != NULL);
+	REQUIRE(!dns_rdataset_isassociated(rdataset));
+
+	dns_rdataset_init(&clone);
+	dns_rdataset_clone(ncacherdataset, &clone);
+	result = dns_rdataset_first(&clone);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdataset_current(&clone, &rdata);
+		isc_buffer_init(&source, rdata.data, rdata.length);
+		isc_buffer_add(&source, rdata.length);
+		dns_name_init(&tname, NULL);
+		isc_buffer_remainingregion(&source, &remaining);
+		dns_name_fromregion(&tname, &remaining);
+		INSIST(remaining.length >= tname.length);
+		isc_buffer_forward(&source, tname.length);
+		remaining.length -= tname.length;
+		remaining.base += tname.length;
+
+		INSIST(remaining.length >= 2);
+		type = isc_buffer_getuint16(&source);
+		remaining.length -= 2;
+		remaining.base += 2;
+
+		if (type != dns_rdatatype_rrsig ||
+		    !dns_name_equal(&tname, name)) {
+			result = dns_rdataset_next(&clone);
+			dns_rdata_reset(&rdata);
+			continue;
+		}
+
+		INSIST(remaining.length >= 1);
+		trust = isc_buffer_getuint8(&source);
+		INSIST(trust <= dns_trust_ultimate);
+		remaining.length -= 1;
+		remaining.base += 1;
+
+		raw = remaining.base;
+		count = raw[0] * 256 + raw[1];
+		INSIST(count > 0);
+		raw += 2;
+		sigregion.length = raw[0] * 256 + raw[1];
+		raw += 2;
+		sigregion.base = raw;
+		dns_rdata_reset(&rdata);
+		dns_rdata_fromregion(&rdata, rdataset->rdclass,
+				     dns_rdatatype_rrsig, &sigregion);
+		(void)dns_rdata_tostruct(&rdata, &rrsig, NULL);
+		if (rrsig.covered == covers) {
+			isc_buffer_remainingregion(&source, &remaining);
+			break;
+		}
+
+		result = dns_rdataset_next(&clone);
+		dns_rdata_reset(&rdata);
+	}
+	dns_rdataset_disassociate(&clone);
+	if (result == ISC_R_NOMORE)
+		return (ISC_R_NOTFOUND);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	INSIST(remaining.length != 0);
+
+	rdataset->methods = &rdataset_methods;
+	rdataset->rdclass = ncacherdataset->rdclass;
+	rdataset->type = dns_rdatatype_rrsig;
+	rdataset->covers = covers;
+	rdataset->ttl = ncacherdataset->ttl;
+	rdataset->trust = trust;
+	rdataset->private1 = NULL;
+	rdataset->private2 = NULL;
+
+	rdataset->private3 = remaining.base;
+
+	/*
+	 * Reset iterator state.
+	 */
+	rdataset->privateuint4 = 0;
+	rdataset->private5 = NULL;
+	rdataset->private6 = NULL;
+	return (ISC_R_SUCCESS);
+}
+
+void
+dns_ncache_current(dns_rdataset_t *ncacherdataset, dns_name_t *found,
+		   dns_rdataset_t *rdataset)
+{
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_trust_t trust;
+	isc_region_t remaining, sigregion;
+	isc_buffer_t source;
+	dns_name_t tname;
+	dns_rdatatype_t type;
+	unsigned int count;
+	dns_rdata_rrsig_t rrsig;
+	unsigned char *raw;
+
+	REQUIRE(ncacherdataset != NULL);
+	REQUIRE(ncacherdataset->type == 0);
+	REQUIRE(found != NULL);
+	REQUIRE(!dns_rdataset_isassociated(rdataset));
+
+	dns_rdataset_current(ncacherdataset, &rdata);
+	isc_buffer_init(&source, rdata.data, rdata.length);
+	isc_buffer_add(&source, rdata.length);
+
+	dns_name_init(&tname, NULL);
+	isc_buffer_remainingregion(&source, &remaining);
+	dns_name_fromregion(found, &remaining);
+	INSIST(remaining.length >= found->length);
+	isc_buffer_forward(&source, found->length);
+	remaining.length -= found->length;
+
+	INSIST(remaining.length >= 5);
+	type = isc_buffer_getuint16(&source);
+	trust = isc_buffer_getuint8(&source);
+	INSIST(trust <= dns_trust_ultimate);
+	isc_buffer_remainingregion(&source, &remaining);
+
+	rdataset->methods = &rdataset_methods;
+	rdataset->rdclass = ncacherdataset->rdclass;
+	rdataset->type = type;
+	if (type == dns_rdatatype_rrsig) {
+		/*
+		 * Extract covers from RRSIG.
+		 */
+		raw = remaining.base;
+		count = raw[0] * 256 + raw[1];
+		INSIST(count > 0);
+		raw += 2;
+		sigregion.length = raw[0] * 256 + raw[1];
+		raw += 2;
+		sigregion.base = raw;
+		dns_rdata_reset(&rdata);
+		dns_rdata_fromregion(&rdata, rdataset->rdclass,
+				     rdataset->type, &sigregion);
+		(void)dns_rdata_tostruct(&rdata, &rrsig, NULL);
+		rdataset->covers = rrsig.covered;
+	} else
+		rdataset->covers = 0;
+	rdataset->ttl = ncacherdataset->ttl;
+	rdataset->trust = trust;
+	rdataset->private1 = NULL;
+	rdataset->private2 = NULL;
+
+	rdataset->private3 = remaining.base;
+
+	/*
+	 * Reset iterator state.
+	 */
+	rdataset->privateuint4 = 0;
+	rdataset->private5 = NULL;
+	rdataset->private6 = NULL;
+}

lib/dns/rbtdb.c

@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbtdb.c,v 1.196.18.61 2010/02/26 23:46:36 tbox Exp $ */
+/* $Id: rbtdb.c,v 1.196.18.64 2010/11/17 10:21:01 marka Exp $ */
 
 /*! \file */
 
@@ -3594,6 +3594,8 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 	 * If we didn't find what we were looking for...
 	 */
 	if (found == NULL ||
+	    (found->trust == dns_trust_additional &&
+	     ((options & DNS_DBFIND_ADDITIONALOK) == 0)) ||
 	    (found->trust == dns_trust_glue &&
 	     ((options & DNS_DBFIND_GLUEOK) == 0)) ||
 	    (DNS_TRUST_PENDING(found->trust) &&
@@ -4406,14 +4408,14 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
     dns_rdataset_t *addedrdataset, isc_stdtime_t now)
 {
 	rbtdb_changed_t *changed = NULL;
-	rdatasetheader_t *topheader, *topheader_prev, *header;
+	rdatasetheader_t *topheader, *topheader_prev, *header, *sigheader;
 	unsigned char *merged;
 	isc_result_t result;
 	isc_boolean_t header_nx;
 	isc_boolean_t newheader_nx;
 	isc_boolean_t merge;
 	dns_rdatatype_t rdtype, covers;
-	rbtdb_rdatatype_t negtype;
+	rbtdb_rdatatype_t negtype, sigtype;
 	dns_trust_t trust;
 
 	/*
@@ -4450,7 +4452,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 
 	newheader_nx = NONEXISTENT(newheader) ? ISC_TRUE : ISC_FALSE;
 	topheader_prev = NULL;
-
+	sigheader = NULL;
 	negtype = 0;
 	if (rbtversion == NULL && !newheader_nx) {
 		rdtype = RBTDB_RDATATYPE_BASE(newheader->type);
@@ -4459,26 +4461,35 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 			 * We're adding a negative cache entry.
 			 */
 			covers = RBTDB_RDATATYPE_EXT(newheader->type);
-			if (covers == dns_rdatatype_any) {
+			sigtype = RBTDB_RDATATYPE_VALUE(dns_rdatatype_rrsig,
+							covers);
+
+			for (topheader = rbtnode->data;
+			     topheader != NULL;
+			     topheader = topheader->next) {
 				/*
-				 * We're adding an negative cache entry
+				 * If we're adding an negative cache entry
 				 * which covers all types (NXDOMAIN,
 				 * NODATA(QTYPE=ANY)).
 				 *
 				 * We make all other data stale so that the
 				 * only rdataset that can be found at this
 				 * node is the negative cache entry.
+				 *
+				 * Otherwise look for any RRSIGs of the
+				 * given type so they can be marked stale
+				 * later.
 				 */
-				for (topheader = rbtnode->data;
-				     topheader != NULL;
-				     topheader = topheader->next) {
+				if (covers == dns_rdatatype_any) {
 					topheader->ttl = 0;
 					topheader->attributes |=
 						RDATASET_ATTR_STALE;
-				}
-				rbtnode->dirty = 1;
-				goto find_header;
+					rbtnode->dirty = 1;
+				} else if (topheader->type == sigtype)
+					sigheader = topheader;
 			}
+			if (covers == dns_rdatatype_any)
+				goto find_header;
 			negtype = RBTDB_RDATATYPE_VALUE(covers, 0);
 		} else {
 			/*
@@ -4700,6 +4711,11 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 			if (rbtversion == NULL) {
 				header->ttl = 0;
 				header->attributes |= RDATASET_ATTR_STALE;
+				if (sigheader != NULL) {
+					sigheader->ttl = 0;
+					sigheader->attributes |=
+						 RDATASET_ATTR_STALE;
+				}
 			}
 		}
 	} else {

lib/dns/rdataset.c

@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataset.c,v 1.72.18.9 2010/02/26 23:46:36 tbox Exp $ */
+/* $Id: rdataset.c,v 1.72.18.9.10.1 2011/05/26 23:56:27 each Exp $ */
 
 /*! \file */
 
@@ -34,6 +34,26 @@
 #include <dns/rdataset.h>
 #include <dns/compress.h>
 
+static const char *trustnames[] = {
+	"none",
+	"pending-additional",
+	"pending-answer",
+	"additional",
+	"glue",
+	"answer",
+	"authauthority",
+	"authanswer",
+	"secure",
+	"local" /* aka ultimate */
+};
+
+const char *
+dns_trust_totext(dns_trust_t trust) {
+	if (trust >= sizeof(trustnames)/sizeof(*trustnames))
+		return ("bad");
+	return (trustnames[trust]);
+}
+
 void
 dns_rdataset_init(dns_rdataset_t *rdataset) {
 

lib/dns/resolver.c

@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.c,v 1.284.18.101 2010/02/26 23:46:36 tbox Exp $ */
+/* $Id: resolver.c,v 1.284.18.103 2010/06/23 23:45:21 tbox Exp $ */
 
 /*! \file */
 
@@ -5612,13 +5612,40 @@ answer_response(fetchctx_t *fctx) {
 	return (result);
 }
 
+static isc_boolean_t
+fctx_decreference(fetchctx_t *fctx) {
+	isc_boolean_t bucket_empty = ISC_FALSE;
+
+	INSIST(fctx->references > 0);
+	fctx->references--;
+	if (fctx->references == 0) {
+		/*
+		 * No one cares about the result of this fetch anymore.
+		 */
+		if (fctx->pending == 0 && fctx->nqueries == 0 &&
+		    ISC_LIST_EMPTY(fctx->validators) && SHUTTINGDOWN(fctx)) {
+			/*
+			 * This fctx is already shutdown; we were just
+			 * waiting for the last reference to go away.
+			 */
+			bucket_empty = fctx_destroy(fctx);
+		} else {
+			/*
+			 * Initiate shutdown.
+			 */
+			fctx_shutdown(fctx);
+		}
+	}
+	return (bucket_empty);
+}
+
 static void
 resume_dslookup(isc_task_t *task, isc_event_t *event) {
 	dns_fetchevent_t *fevent;
 	dns_resolver_t *res;
 	fetchctx_t *fctx;
 	isc_result_t result;
-	isc_boolean_t bucket_empty = ISC_FALSE;
+	isc_boolean_t bucket_empty;
 	isc_boolean_t locked = ISC_FALSE;
 	unsigned int bucketnum;
 	dns_rdataset_t nameservers;
@@ -5722,9 +5749,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 	isc_event_free(&event);
 	if (!locked)
 		LOCK(&res->buckets[bucketnum].lock);
-	fctx->references--;
-	if (fctx->references == 0)
-		bucket_empty = fctx_destroy(fctx);
+	bucket_empty = fctx_decreference(fctx);
 	UNLOCK(&res->buckets[bucketnum].lock);
 	if (bucket_empty)
 		empty_bucket(res);
@@ -6449,12 +6474,14 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 						  &fctx->nsfetch);
 		if (result != ISC_R_SUCCESS)
 			fctx_done(fctx, result, __LINE__);
-		LOCK(&fctx->res->buckets[fctx->bucketnum].lock);
-		fctx->references++;
-		UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
-		result = fctx_stopidletimer(fctx);
-		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result, __LINE__);
+		else {
+			LOCK(&fctx->res->buckets[fctx->bucketnum].lock);
+			fctx->references++;
+			UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
+			result = fctx_stopidletimer(fctx);
+			if (result != ISC_R_SUCCESS)
+				fctx_done(fctx, result, __LINE__);
+		}
 	} else {
 		/*
 		 * We're done.
@@ -7288,7 +7315,7 @@ dns_resolver_destroyfetch(dns_fetch_t **fetchp) {
 	dns_fetchevent_t *event, *next_event;
 	fetchctx_t *fctx;
 	unsigned int bucketnum;
-	isc_boolean_t bucket_empty = ISC_FALSE;
+	isc_boolean_t bucket_empty;
 
 	REQUIRE(fetchp != NULL);
 	fetch = *fetchp;
@@ -7316,27 +7343,7 @@ dns_resolver_destroyfetch(dns_fetch_t **fetchp) {
 		}
 	}
 
-	INSIST(fctx->references > 0);
-	fctx->references--;
-	if (fctx->references == 0) {
-		/*
-		 * No one cares about the result of this fetch anymore.
-		 */
-		if (fctx->pending == 0 && fctx->nqueries == 0 &&
-		    ISC_LIST_EMPTY(fctx->validators) &&
-		    SHUTTINGDOWN(fctx)) {
-			/*
-			 * This fctx is already shutdown; we were just
-			 * waiting for the last reference to go away.
-			 */
-			bucket_empty = fctx_destroy(fctx);
-		} else {
-			/*
-			 * Initiate shutdown.
-			 */
-			fctx_shutdown(fctx);
-		}
-	}
+	bucket_empty = fctx_decreference(fctx);
 
 	UNLOCK(&res->buckets[bucketnum].lock);
 

lib/dns/validator.c

@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.c,v 1.119.18.54 2010/04/21 04:23:47 marka Exp $ */
+/* $Id: validator.c,v 1.119.18.60.6.1 2011/05/26 23:56:27 each Exp $ */
 
 /*! \file */
 
@@ -113,6 +113,10 @@
 #define NEEDNOQNAME(val) ((val->attributes & VALATTR_NEEDNOQNAME) != 0)
 #define NEEDNOWILDCARD(val) ((val->attributes & VALATTR_NEEDNOWILDCARD) != 0)
 #define DLVTRIED(val) ((val->attributes & VALATTR_DLVTRIED) != 0)
+#define FOUNDNODATA(val) ((val->attributes & VALATTR_FOUNDNODATA) != 0)
+#define FOUNDNOQNAME(val) ((val->attributes & VALATTR_FOUNDNOQNAME) != 0)
+#define FOUNDNOWILDCARD(val) ((val->attributes & VALATTR_FOUNDNOWILDCARD) != 0)
+#define FOUNDOPTOUT(val) ((val->attributes & VALATTR_FOUNDOPTOUT) != 0)
 
 #define SHUTDOWN(v)		(((v)->attributes & VALATTR_SHUTDOWN) != 0)
 #define CANCELED(v)		(((v)->attributes & VALATTR_CANCELED) != 0)
@@ -167,8 +171,8 @@ startfinddlvsep(dns_validator_t *val, dns_name_t *unsecure);
  * Mark the RRsets as a answer.
  */
 static inline void
-markanswer(dns_validator_t *val) {
-	validator_log(val, ISC_LOG_DEBUG(3), "marking as answer");
+markanswer(dns_validator_t *val, const char *where) {
+	validator_log(val, ISC_LOG_DEBUG(3), "marking as answer (%s)", where);
 	if (val->event->rdataset != NULL)
 		dns_rdataset_settrust(val->event->rdataset, dns_trust_answer);
 	if (val->event->sigrdataset != NULL)
@@ -179,7 +183,8 @@ markanswer(dns_validator_t *val) {
 static inline void
 marksecure(dns_validatorevent_t *event) {
 	dns_rdataset_settrust(event->rdataset, dns_trust_secure);
-	dns_rdataset_settrust(event->sigrdataset, dns_trust_secure);
+	if (event->sigrdataset != NULL)
+		dns_rdataset_settrust(event->sigrdataset, dns_trust_secure);
 }
 
 static void
@@ -299,6 +304,7 @@ fetch_callback_validator(isc_task_t *task, isc_event_t *event) {
 	isc_boolean_t want_destroy;
 	isc_result_t result;
 	isc_result_t eresult;
+	isc_result_t saved_result;
 
 	UNUSED(task);
 	INSIST(event->ev_type == DNS_EVENT_FETCHDONE);
@@ -325,7 +331,8 @@ fetch_callback_validator(isc_task_t *task, isc_event_t *event) {
 		validator_done(val, ISC_R_CANCELED);
 	} else if (eresult == ISC_R_SUCCESS) {
 		validator_log(val, ISC_LOG_DEBUG(3),
-			      "keyset with trust %d", rdataset->trust);
+			      "keyset with trust %s",
+			      dns_trust_totext(rdataset->trust));
 		/*
 		 * Only extract the dst key if the keyset is secure.
 		 */
@@ -335,6 +342,17 @@ fetch_callback_validator(isc_task_t *task, isc_event_t *event) {
 				val->keyset = &val->frdataset;
 		}
 		result = validate(val, ISC_TRUE);
+		if (result == DNS_R_NOVALIDSIG &&
+		    (val->attributes & VALATTR_TRIEDVERIFY) == 0)
+		{
+			saved_result = result;
+			validator_log(val, ISC_LOG_DEBUG(3),
+				      "falling back to insecurity proof");
+			val->attributes |= VALATTR_INSECURITY;
+			result = proveunsecure(val, ISC_FALSE, ISC_FALSE);
+			if (result == DNS_R_NOTINSECURE)
+				result = saved_result;
+		}
 		if (result != DNS_R_WAIT)
 			validator_done(val, result);
 	} else {
@@ -391,7 +409,8 @@ dsfetched(isc_task_t *task, isc_event_t *event) {
 		validator_done(val, ISC_R_CANCELED);
 	} else if (eresult == ISC_R_SUCCESS) {
 		validator_log(val, ISC_LOG_DEBUG(3),
-			      "dsset with trust %d", rdataset->trust);
+			      "dsset with trust %s",
+			       dns_trust_totext(rdataset->trust));
 		val->dsset = &val->frdataset;
 		result = validatezonekey(val);
 		if (result != DNS_R_WAIT)
@@ -475,7 +494,7 @@ dsfetched2(isc_task_t *task, isc_event_t *event) {
 					      "must be secure failure");
 				validator_done(val, DNS_R_MUSTBESECURE);
 			} else if (val->view->dlv == NULL || DLVTRIED(val)) {
-				markanswer(val);
+				markanswer(val, "dsfetched2");
 				validator_done(val, ISC_R_SUCCESS);
 			} else {
 				result = startfinddlvsep(val, tname);
@@ -525,6 +544,7 @@ keyvalidated(isc_task_t *task, isc_event_t *event) {
 	isc_boolean_t want_destroy;
 	isc_result_t result;
 	isc_result_t eresult;
+	isc_result_t saved_result;
 
 	UNUSED(task);
 	INSIST(event->ev_type == DNS_EVENT_VALIDATORDONE);
@@ -544,13 +564,25 @@ keyvalidated(isc_task_t *task, isc_event_t *event) {
 		validator_done(val, ISC_R_CANCELED);
 	} else if (eresult == ISC_R_SUCCESS) {
 		validator_log(val, ISC_LOG_DEBUG(3),
-			      "keyset with trust %d", val->frdataset.trust);
+			      "keyset with trust %s",
+			      dns_trust_totext(val->frdataset.trust));
 		/*
 		 * Only extract the dst key if the keyset is secure.
 		 */
 		if (val->frdataset.trust >= dns_trust_secure)
 			(void) get_dst_key(val, val->siginfo, &val->frdataset);
 		result = validate(val, ISC_TRUE);
+		if (result == DNS_R_NOVALIDSIG &&
+		    (val->attributes & VALATTR_TRIEDVERIFY) == 0)
+		{
+			saved_result = result;
+			validator_log(val, ISC_LOG_DEBUG(3),
+				      "falling back to insecurity proof");
+			val->attributes |= VALATTR_INSECURITY;
+			result = proveunsecure(val, ISC_FALSE, ISC_FALSE);
+			if (result == DNS_R_NOTINSECURE)
+				result = saved_result;
+		}
 		if (result != DNS_R_WAIT)
 			validator_done(val, result);
 	} else {
@@ -601,11 +633,32 @@ dsvalidated(isc_task_t *task, isc_event_t *event) {
 	if (CANCELED(val)) {
 		validator_done(val, ISC_R_CANCELED);
 	} else if (eresult == ISC_R_SUCCESS) {
+		isc_boolean_t have_dsset;
+		dns_name_t *name;
 		validator_log(val, ISC_LOG_DEBUG(3),
-			      "dsset with trust %d", val->frdataset.trust);
-		if ((val->attributes & VALATTR_INSECURITY) != 0)
-			result = proveunsecure(val, ISC_TRUE, ISC_TRUE);
-		else
+			      "%s with trust %s",
+			      val->frdataset.type == dns_rdatatype_ds ?
+			      "dsset" : "ds non-existance",
+			      dns_trust_totext(val->frdataset.trust));
+		have_dsset = ISC_TF(val->frdataset.type == dns_rdatatype_ds);
+		name = dns_fixedname_name(&val->fname);
+		if ((val->attributes & VALATTR_INSECURITY) != 0 &&
+		    val->frdataset.covers == dns_rdatatype_ds &&
+		    val->frdataset.type == 0 &&
+		    isdelegation(name, &val->frdataset, DNS_R_NCACHENXRRSET)) {
+			if (val->mustbesecure) {
+				validator_log(val, ISC_LOG_WARNING,
+					      "must be secure failure, no DS "
+					      "and this is a delegation");
+				result = DNS_R_MUSTBESECURE;
+			} else if (val->view->dlv == NULL || DLVTRIED(val)) {
+				markanswer(val, "dsvalidated");
+				result = ISC_R_SUCCESS;;
+			} else
+				result = startfinddlvsep(val, name);
+		} else if ((val->attributes & VALATTR_INSECURITY) != 0) {
+			result = proveunsecure(val, have_dsset, ISC_TRUE);
+		} else
 			result = validatezonekey(val);
 		if (result != DNS_R_WAIT)
 			validator_done(val, result);
@@ -839,10 +892,8 @@ authvalidated(isc_task_t *task, isc_event_t *event) {
 
 		if (rdataset->type == dns_rdatatype_nsec &&
 		    rdataset->trust == dns_trust_secure &&
-		    ((val->attributes & VALATTR_NEEDNODATA) != 0 ||
-		     (val->attributes & VALATTR_NEEDNOQNAME) != 0) &&
-		    (val->attributes & VALATTR_FOUNDNODATA) == 0 &&
-		    (val->attributes & VALATTR_FOUNDNOQNAME) == 0 &&
+		    (NEEDNODATA(val) || NEEDNOQNAME(val)) &&
+		    !FOUNDNODATA(val) && !FOUNDNOQNAME(val) &&
 		    nsecnoexistnodata(val, val->event->name, devent->name,
 				      rdataset, &exists, &data, wild)
 				      == ISC_R_SUCCESS)
@@ -945,8 +996,8 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
 		INSIST(type == dns_rdatatype_dlv);
 		if (val->frdataset.trust != dns_trust_secure) {
 			validator_log(val, ISC_LOG_DEBUG(3),
-				      "covering nsec: trust %u",
-				      val->frdataset.trust);
+				      "covering nsec: trust %s",
+				      dns_trust_totext(val->frdataset.trust));
 			goto notfound;
 		}
 		result = dns_rdataset_first(&val->frdataset);
@@ -1227,11 +1278,14 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
 		 * We have an rrset for the given keyname.
 		 */
 		val->keyset = &val->frdataset;
-		if (DNS_TRUST_PENDING(val->frdataset.trust) &&
+		if ((DNS_TRUST_PENDING(val->frdataset.trust) ||
+		     DNS_TRUST_ANSWER(val->frdataset.trust)) &&
 		    dns_rdataset_isassociated(&val->fsigrdataset))
 		{
 			/*
-			 * We know the key but haven't validated it yet.
+			 * We know the key but haven't validated it yet or
+			 * we have a key of trust answer but a DS/DLV
+			 * record for the zone may have been added.
 			 */
 			result = create_validator(val, &siginfo->signer,
 						  dns_rdatatype_dnskey,
@@ -1260,8 +1314,8 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
 			 * See if we've got the key used in the signature.
 			 */
 			validator_log(val, ISC_LOG_DEBUG(3),
-				      "keyset with trust %d",
-				      val->frdataset.trust);
+				      "keyset with trust %s",
+				      dns_trust_totext(val->frdataset.trust));
 			result = get_dst_key(val, siginfo, val->keyset);
 			if (result != ISC_R_SUCCESS) {
 				/*
@@ -1453,9 +1507,11 @@ validate(dns_validator_t *val, isc_boolean_t resume) {
 		 * was known and "sufficiently good".
 		 */
 		if (!dns_resolver_algorithm_supported(val->view->resolver,
-						      event->name,
-						      val->siginfo->algorithm))
+						    event->name,
+						    val->siginfo->algorithm)) {
+			resume = ISC_FALSE;
 			continue;
+		}
 
 		if (!resume) {
 			result = get_key(val, val->siginfo);
@@ -1466,16 +1522,12 @@ validate(dns_validator_t *val, isc_boolean_t resume) {
 		}
 
 		/*
-		 * The key is insecure, so mark the data as insecure also.
+		 * There isn't a secure DNSKEY for this signature so move
+		 * onto the next RRSIG.
 		 */
 		if (val->key == NULL) {
-			if (val->mustbesecure) {
-				validator_log(val, ISC_LOG_WARNING,
-					      "must be secure failure");
-				return (DNS_R_MUSTBESECURE);
-			}
-			markanswer(val);
-			return (ISC_R_SUCCESS);
+			resume = ISC_FALSE;
+			continue;
 		}
 
 		do {
@@ -1531,7 +1583,7 @@ validate(dns_validator_t *val, isc_boolean_t resume) {
 			}
 		}
 		val->key = NULL;
-		if ((val->attributes & VALATTR_NEEDNOQNAME) != 0) {
+		if (NEEDNOQNAME(val)) {
 			if (val->event->message == NULL) {
 				validator_log(val, ISC_LOG_DEBUG(3),
 				      "no message available for noqname proof");
@@ -1728,7 +1780,7 @@ dlv_validatezonekey(dns_validator_t *val) {
 		}
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "no supported algorithm/digest (dlv)");
-		markanswer(val);
+		markanswer(val, "dlv_validatezonekey (2)");
 		return (ISC_R_SUCCESS);
 	} else
 		return (DNS_R_NOVALIDSIG);
@@ -1774,6 +1826,17 @@ validatezonekey(dns_validator_t *val) {
 		return (dlv_validatezonekey(val));
 
 	if (val->dsset == NULL) {
+
+		/*
+		 * We have a dlv sep.  Skip looking up the SEP from
+		 * {trusted,managed}-keys.  If the dlv sep is for the
+		 * root then it will have been handled above so we don't
+		 * need to check whether val->event->name is "." prior to
+		 * looking up the DS.
+		 */
+		if (val->havedlvsep)
+			goto find_ds;
+
 		/*
 		 * First, see if this key was signed by a trusted key.
 		 */
@@ -1781,8 +1844,12 @@ validatezonekey(dns_validator_t *val) {
 		     result == ISC_R_SUCCESS;
 		     result = dns_rdataset_next(val->event->sigrdataset))
 		{
-			dns_keynode_t *keynode = NULL, *nextnode = NULL;
+			dns_keynode_t *keynode = NULL;
+			dns_fixedname_t fixed;
+			dns_name_t *found;
 
+			dns_fixedname_init(&fixed);
+			found = dns_fixedname_name(&fixed);
 			dns_rdata_reset(&sigrdata);
 			dns_rdataset_current(val->event->sigrdataset,
 					     &sigrdata);
@@ -1797,10 +1864,28 @@ validatezonekey(dns_validator_t *val) {
 							  sig.algorithm,
 							  sig.keyid,
 							  &keynode);
+			if (result == ISC_R_NOTFOUND &&
+			    dns_keytable_finddeepestmatch(val->keytable,
+				  val->event->name, found) != ISC_R_SUCCESS) {
+				if (val->mustbesecure) {
+					validator_log(val, ISC_LOG_WARNING,
+						     "must be secure failure, "
+						     "not beneath secure root");
+					return (DNS_R_MUSTBESECURE);
+				} else
+					validator_log(val, ISC_LOG_DEBUG(3),
+						     "not beneath secure root");
+				if (val->view->dlv == NULL) {
+					markanswer(val, "validatezonekey (1)");
+					return (ISC_R_SUCCESS);
+				}
+				return (startfinddlvsep(val, dns_rootname));
+			}
 			if (result == DNS_R_PARTIALMATCH ||
 			    result == ISC_R_SUCCESS)
 				atsep = ISC_TRUE;
 			while (result == ISC_R_SUCCESS) {
+				dns_keynode_t *nextnode = NULL;
 				dstkey = dns_keynode_key(keynode);
 				result = verify(val, dstkey, &sigrdata,
 						sig.keyid);
@@ -1826,17 +1911,6 @@ validatezonekey(dns_validator_t *val) {
 			}
 		}
 
-		/*
-		 * If this is the root name and there was no trusted key,
-		 * give up, since there's no DS at the root.
-		 */
-		if (dns_name_equal(event->name, dns_rootname)) {
-			if ((val->attributes & VALATTR_TRIEDVERIFY) != 0)
-				return (DNS_R_NOVALIDSIG);
-			else
-				return (DNS_R_NOVALIDDS);
-		}
-
 		if (atsep) {
 			/*
 			 * We have not found a key to verify this DNSKEY
@@ -1856,6 +1930,22 @@ validatezonekey(dns_validator_t *val) {
 			return (DNS_R_NOVALIDKEY);
 		}
 
+		/*
+		 * If this is the root name and there was no trusted key,
+		 * give up, since there's no DS at the root.
+		 */
+		if (dns_name_equal(event->name, dns_rootname)) {
+			if ((val->attributes & VALATTR_TRIEDVERIFY) != 0) {
+				validator_log(val, ISC_LOG_DEBUG(3),
+					      "root key failed to validate");
+				return (DNS_R_NOVALIDSIG);
+			} else {
+				validator_log(val, ISC_LOG_DEBUG(3),
+					      "no trusted root key");
+				return (DNS_R_NOVALIDDS);
+			}
+		}
+ find_ds:
 		/*
 		 * Otherwise, try to find the DS record.
 		 */
@@ -1865,7 +1955,8 @@ validatezonekey(dns_validator_t *val) {
 			 * We have DS records.
 			 */
 			val->dsset = &val->frdataset;
-			if (DNS_TRUST_PENDING(val->frdataset.trust) &&
+			if ((DNS_TRUST_PENDING(val->frdataset.trust) ||
+			     DNS_TRUST_ANSWER(val->frdataset.trust)) &&
 			    dns_rdataset_isassociated(&val->fsigrdataset))
 			{
 				result = create_validator(val,
@@ -1928,8 +2019,11 @@ validatezonekey(dns_validator_t *val) {
 				      "must be secure failure");
 			return (DNS_R_MUSTBESECURE);
 		}
-		markanswer(val);
-		return (ISC_R_SUCCESS);
+		if (val->view->dlv == NULL || DLVTRIED(val)) {
+			markanswer(val, "validatezonekey (2)");
+			return (ISC_R_SUCCESS);
+		}
+		return (startfinddlvsep(val, val->event->name));
 	}
 
 	/*
@@ -2074,7 +2168,7 @@ validatezonekey(dns_validator_t *val) {
 		}
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "no supported algorithm/digest (DS)");
-		markanswer(val);
+		markanswer(val, "validatezonekey (3)");
 		return (ISC_R_SUCCESS);
 	} else
 		return (DNS_R_NOVALIDSIG);
@@ -2100,6 +2194,80 @@ start_positive_validation(dns_validator_t *val) {
 	return (validatezonekey(val));
 }
 
+/*%
+ * val_rdataset_first and val_rdataset_next provide iteration methods
+ * that hide whether we are iterating across a message or a  negative
+ * cache rdataset.
+ */
+static isc_result_t
+val_rdataset_first(dns_validator_t *val, dns_name_t **namep,
+		   dns_rdataset_t **rdatasetp)
+{
+	dns_message_t *message = val->event->message;
+	isc_result_t result;
+
+	REQUIRE(rdatasetp != NULL);
+	REQUIRE(namep != NULL);
+	if (message == NULL) {
+		REQUIRE(*rdatasetp != NULL);
+		REQUIRE(*namep != NULL);
+	} else {
+		REQUIRE(*rdatasetp == NULL);
+		REQUIRE(*namep == NULL);
+	}
+
+	if (message != NULL) {
+		result = dns_message_firstname(message, DNS_SECTION_AUTHORITY);
+		if (result != ISC_R_SUCCESS)
+			return (result);
+		dns_message_currentname(message, DNS_SECTION_AUTHORITY, namep);
+		*rdatasetp = ISC_LIST_HEAD((*namep)->list);
+		INSIST(*rdatasetp != NULL);
+	} else {
+		result = dns_rdataset_first(val->event->rdataset);
+		if (result == ISC_R_SUCCESS)
+			dns_ncache_current(val->event->rdataset, *namep,
+					   *rdatasetp);
+	}
+	return (result);
+}
+
+static isc_result_t
+val_rdataset_next(dns_validator_t *val, dns_name_t **namep,
+		  dns_rdataset_t **rdatasetp)
+{
+	dns_message_t *message = val->event->message;
+	isc_result_t result = ISC_R_SUCCESS;
+
+	REQUIRE(rdatasetp != NULL && *rdatasetp != NULL);
+	REQUIRE(namep != NULL && *namep != NULL);
+
+	if (message != NULL) {
+		dns_rdataset_t *rdataset = *rdatasetp;
+		rdataset = ISC_LIST_NEXT(rdataset, link);
+		if (rdataset == NULL) {
+			*namep = NULL;
+			result = dns_message_nextname(message,
+						      DNS_SECTION_AUTHORITY);
+			if (result == ISC_R_SUCCESS) {
+				dns_message_currentname(message,
+							DNS_SECTION_AUTHORITY,
+							namep);
+				rdataset = ISC_LIST_HEAD((*namep)->list);
+				INSIST(rdataset != NULL);
+			}
+		}
+		*rdatasetp = rdataset;
+	} else {
+		dns_rdataset_disassociate(*rdatasetp);
+		result = dns_rdataset_next(val->event->rdataset);
+		if (result == ISC_R_SUCCESS)
+			dns_ncache_current(val->event->rdataset, *namep,
+					   *rdatasetp);
+	}
+	return (result);
+}
+
 /*%
  * Look for NODATA at the wildcard and NOWILDCARD proofs in the
  * previously validated NSEC records.  As these proofs are mutually
@@ -2110,100 +2278,81 @@ start_positive_validation(dns_validator_t *val) {
  */
 static isc_result_t
 checkwildcard(dns_validator_t *val) {
-	dns_name_t *name, *wild;
-	dns_message_t *message = val->event->message;
+	dns_name_t *name, *wild, tname;
 	isc_result_t result;
 	isc_boolean_t exists, data;
 	char namebuf[DNS_NAME_FORMATSIZE];
+	dns_rdataset_t *rdataset, trdataset;
 
+	dns_name_init(&tname, NULL);
+	dns_rdataset_init(&trdataset);
 	wild = dns_fixedname_name(&val->wild);
 	dns_name_format(wild, namebuf, sizeof(namebuf));
 	validator_log(val, ISC_LOG_DEBUG(3), "in checkwildcard: %s", namebuf);
 
-	for (result = dns_message_firstname(message, DNS_SECTION_AUTHORITY);
-	     result == ISC_R_SUCCESS;
-	     result = dns_message_nextname(message, DNS_SECTION_AUTHORITY))
-	{
-		dns_rdataset_t *rdataset = NULL, *sigrdataset = NULL;
-
+	if (val->event->message == NULL) {
+		name = &tname;
+		rdataset = &trdataset;
+	} else {
 		name = NULL;
-		dns_message_currentname(message, DNS_SECTION_AUTHORITY, &name);
+		rdataset = NULL;
+	}
 
-		for (rdataset = ISC_LIST_HEAD(name->list);
-		     rdataset != NULL;
-		     rdataset = ISC_LIST_NEXT(rdataset, link))
+	for (result = val_rdataset_first(val, &name, &rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = val_rdataset_next(val, &name, &rdataset))
+	{
+		if (rdataset->type != dns_rdatatype_nsec ||
+		    rdataset->trust != dns_trust_secure)
+			continue;
+		val->nsecset = rdataset;
+
+		if (rdataset->trust != dns_trust_secure)
+			continue;
+
+		if ((NEEDNODATA(val) || NEEDNOWILDCARD(val)) &&
+		    !FOUNDNODATA(val) && !FOUNDNOWILDCARD(val) &&
+		    nsecnoexistnodata(val, wild, name, rdataset,
+				      &exists, &data, NULL)
+				       == ISC_R_SUCCESS)
 		{
-			if (rdataset->type != dns_rdatatype_nsec)
-				continue;
-			val->nsecset = rdataset;
-
-			for (sigrdataset = ISC_LIST_HEAD(name->list);
-			     sigrdataset != NULL;
-			     sigrdataset = ISC_LIST_NEXT(sigrdataset, link))
-			{
-				if (sigrdataset->type == dns_rdatatype_rrsig &&
-				    sigrdataset->covers == rdataset->type)
-					break;
-			}
-			if (sigrdataset == NULL)
-				continue;
-
-			if (rdataset->trust != dns_trust_secure)
-				continue;
-
-			if (((val->attributes & VALATTR_NEEDNODATA) != 0 ||
-			     (val->attributes & VALATTR_NEEDNOWILDCARD) != 0) &&
-			    (val->attributes & VALATTR_FOUNDNODATA) == 0 &&
-			    (val->attributes & VALATTR_FOUNDNOWILDCARD) == 0 &&
-			    nsecnoexistnodata(val, wild, name, rdataset,
-					      &exists, &data, NULL)
-					       == ISC_R_SUCCESS)
-			{
-				dns_name_t **proofs = val->event->proofs;
-				if (exists && !data)
-					val->attributes |= VALATTR_FOUNDNODATA;
-				if (exists && !data && NEEDNODATA(val))
-					proofs[DNS_VALIDATOR_NODATAPROOF] =
-							 name;
-				if (!exists)
-					val->attributes |=
-						 VALATTR_FOUNDNOWILDCARD;
-				if (!exists && NEEDNOQNAME(val))
-					proofs[DNS_VALIDATOR_NOWILDCARDPROOF] =
-							 name;
-				return (ISC_R_SUCCESS);
-			}
+			dns_name_t **proofs = val->event->proofs;
+			if (exists && !data)
+				val->attributes |= VALATTR_FOUNDNODATA;
+			if (exists && !data && NEEDNODATA(val))
+				proofs[DNS_VALIDATOR_NODATAPROOF] =
+						 name;
+			if (!exists)
+				val->attributes |=
+					 VALATTR_FOUNDNOWILDCARD;
+			if (!exists && NEEDNOQNAME(val))
+				proofs[DNS_VALIDATOR_NOWILDCARDPROOF] =
+						 name;
+			if (dns_rdataset_isassociated(&trdataset))
+				dns_rdataset_disassociate(&trdataset);
+			return (ISC_R_SUCCESS);
 		}
 	}
 	if (result == ISC_R_NOMORE)
 		result = ISC_R_SUCCESS;
+	if (dns_rdataset_isassociated(&trdataset))
+		dns_rdataset_disassociate(&trdataset);
 	return (result);
 }
 
 /*%
- * Prove a negative answer is good or that there is a NOQNAME when the
- * answer is from a wildcard.
- *
- * Loop through the authority section looking for NODATA, NOWILDCARD
- * and NOQNAME proofs in the NSEC records by calling authvalidated().
- *
- * If the required proofs are found we are done.
- *
- * If the proofs are not found attempt to prove this is a unsecure
- * response.
+ * Validate the authority section records.
  */
 static isc_result_t
-nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
+validate_authority(dns_validator_t *val, isc_boolean_t resume) {
 	dns_name_t *name;
 	dns_message_t *message = val->event->message;
 	isc_result_t result;
 
 	if (!resume)
 		result = dns_message_firstname(message, DNS_SECTION_AUTHORITY);
-	else {
+	else
 		result = ISC_R_SUCCESS;
-		validator_log(val, ISC_LOG_DEBUG(3), "resuming nsecvalidate");
-	}
 
 	for (;
 	     result == ISC_R_SUCCESS;
@@ -2266,16 +2415,121 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 			result = create_validator(val, name, rdataset->type,
 						  rdataset, sigrdataset,
 						  authvalidated,
-						  "nsecvalidate");
+						  "validate_authority");
 			if (result != ISC_R_SUCCESS)
 				return (result);
 			val->authcount++;
 			return (DNS_R_WAIT);
-
 		}
 	}
 	if (result == ISC_R_NOMORE)
 		result = ISC_R_SUCCESS;
+	return (result);
+}
+
+/*%
+ * Validate the ncache elements.
+ */
+static isc_result_t
+validate_ncache(dns_validator_t *val, isc_boolean_t resume) {
+	dns_name_t *name;
+	isc_result_t result;
+
+	if (!resume)
+		result = dns_rdataset_first(val->event->rdataset);
+	else
+		result = dns_rdataset_next(val->event->rdataset);
+
+	for (;
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(val->event->rdataset))
+	{
+		dns_rdataset_t *rdataset, *sigrdataset = NULL;
+
+		if (dns_rdataset_isassociated(&val->frdataset))
+			dns_rdataset_disassociate(&val->frdataset);
+		if (dns_rdataset_isassociated(&val->fsigrdataset))
+			dns_rdataset_disassociate(&val->fsigrdataset);
+
+		dns_fixedname_init(&val->fname);
+		name = dns_fixedname_name(&val->fname);
+		rdataset = &val->frdataset;
+		dns_ncache_current(val->event->rdataset, name, rdataset);
+
+		if (val->frdataset.type == dns_rdatatype_rrsig)
+			continue;
+
+		result = dns_ncache_getsigrdataset(val->event->rdataset, name,
+						   rdataset->type,
+						   &val->fsigrdataset);
+		if (result == ISC_R_SUCCESS)
+			sigrdataset = &val->fsigrdataset;
+
+		/*
+		 * If a signed zone is missing the zone key, bad
+		 * things could happen.  A query for data in the zone
+		 * would lead to a query for the zone key, which
+		 * would return a negative answer, which would contain
+		 * an SOA and an NSEC signed by the missing key, which
+		 * would trigger another query for the DNSKEY (since
+		 * the first one is still in progress), and go into an
+		 * infinite loop.  Avoid that.
+		 */
+		if (val->event->type == dns_rdatatype_dnskey &&
+		    dns_name_equal(name, val->event->name))
+		{
+			dns_rdata_t nsec = DNS_RDATA_INIT;
+
+			if (rdataset->type != dns_rdatatype_nsec)
+				continue;
+
+			result = dns_rdataset_first(rdataset);
+			if (result != ISC_R_SUCCESS)
+				return (result);
+			dns_rdataset_current(rdataset, &nsec);
+			if (dns_nsec_typepresent(&nsec,
+						dns_rdatatype_soa))
+				continue;
+		}
+		val->currentset = rdataset;
+		result = create_validator(val, name, rdataset->type,
+					  rdataset, sigrdataset,
+					  authvalidated,
+					  "validate_ncache");
+		if (result != ISC_R_SUCCESS)
+			return (result);
+		val->authcount++;
+		return (DNS_R_WAIT);
+	}
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+	return (result);
+}
+
+/*%
+ * Prove a negative answer is good or that there is a NOQNAME when the
+ * answer is from a wildcard.
+ *
+ * Loop through the authority section looking for NODATA, NOWILDCARD
+ * and NOQNAME proofs in the NSEC records by calling authvalidated().
+ *
+ * If the required proofs are found we are done.
+ *
+ * If the proofs are not found attempt to prove this is a unsecure
+ * response.
+ */
+static isc_result_t
+nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
+	isc_result_t result;
+
+	if (resume)
+		validator_log(val, ISC_LOG_DEBUG(3), "resuming nsecvalidate");
+
+	if (val->event->message == NULL)
+		result = validate_ncache(val, resume);
+	else
+		result = validate_authority(val, resume);
+
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
@@ -2302,23 +2556,20 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 	/*
 	 * Do we need to check for the wildcard?
 	 */
-	if ((val->attributes & VALATTR_FOUNDNOQNAME) != 0 &&
-	    (((val->attributes & VALATTR_NEEDNODATA) != 0 &&
-	      (val->attributes & VALATTR_FOUNDNODATA) == 0) ||
-	     (val->attributes & VALATTR_NEEDNOWILDCARD) != 0)) {
+	if (FOUNDNOQNAME(val) &&
+	    ((NEEDNODATA(val) && !FOUNDNODATA(val)) || NEEDNOWILDCARD(val))) {
 		result = checkwildcard(val);
 		if (result != ISC_R_SUCCESS)
 			return (result);
 	}
 
-	if (((val->attributes & VALATTR_NEEDNODATA) != 0 &&
-	     (val->attributes & VALATTR_FOUNDNODATA) != 0) ||
-	    ((val->attributes & VALATTR_NEEDNOQNAME) != 0 &&
-	     (val->attributes & VALATTR_FOUNDNOQNAME) != 0 &&
-	     (val->attributes & VALATTR_NEEDNOWILDCARD) != 0 &&
-	     (val->attributes & VALATTR_FOUNDNOWILDCARD) != 0)) {
+	if ((NEEDNODATA(val) && FOUNDNODATA(val)) ||
+	    (NEEDNOQNAME(val) && FOUNDNOQNAME(val) &&
+	     NEEDNOWILDCARD(val) && FOUNDNOWILDCARD(val))) {
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "nonexistence proof(s) found");
+		if (val->event->message == NULL)
+			marksecure(val->event);
 		return (ISC_R_SUCCESS);
 	}
 
@@ -2380,13 +2631,14 @@ dlvvalidated(isc_task_t *task, isc_event_t *event) {
 		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);
+			      "dlvset with trust %s",
+			      dns_trust_totext(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);
+			markanswer(val, "dlvvalidated");
 			validator_done(val, ISC_R_SUCCESS);
 		}
 	} else {
@@ -2455,7 +2707,7 @@ dlvfetched(isc_task_t *task, isc_event_t *event) {
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "DLV %s found with no supported algorithms",
 				      namebuf);
-			markanswer(val);
+			markanswer(val, "dlvfetched (1)");
 			validator_done(val, ISC_R_SUCCESS);
 		}
 	} else if (eresult == DNS_R_NXRRSET ||
@@ -2474,12 +2726,12 @@ dlvfetched(isc_task_t *task, isc_event_t *event) {
 				validator_log(val, ISC_LOG_DEBUG(3),
 					      "DLV %s found with no supported "
 					      "algorithms", namebuf);
-				markanswer(val);
+				markanswer(val, "dlvfetched (2)");
 				validator_done(val, ISC_R_SUCCESS);
 			}
 		} else if (result == ISC_R_NOTFOUND) {
 			validator_log(val, ISC_LOG_DEBUG(3), "DLV not found");
-			markanswer(val);
+			markanswer(val, "dlvfetched (3)");
 			validator_done(val, ISC_R_SUCCESS);
 		} else {
 			validator_log(val, ISC_LOG_DEBUG(3), "DLV lookup: %s",
@@ -2529,7 +2781,7 @@ startfinddlvsep(dns_validator_t *val, dns_name_t *unsecure) {
 	result = finddlvsep(val, ISC_FALSE);
 	if (result == ISC_R_NOTFOUND) {
 		validator_log(val, ISC_LOG_DEBUG(3), "DLV not found");
-		markanswer(val);
+		markanswer(val, "startfinddlvsep (1)");
 		return (ISC_R_SUCCESS);
 	}
 	if (result != ISC_R_SUCCESS) {
@@ -2546,7 +2798,7 @@ startfinddlvsep(dns_validator_t *val, dns_name_t *unsecure) {
 	}
 	validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found with no supported "
 		      "algorithms", namebuf);
-	markanswer(val);
+	markanswer(val, "startfinddlvsep (2)");
 	validator_done(val, ISC_R_SUCCESS);
 	return (ISC_R_SUCCESS);
 }
@@ -2731,7 +2983,7 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 				goto out;
 			}
 			if (val->view->dlv == NULL || DLVTRIED(val)) {
-				markanswer(val);
+				markanswer(val, "proveunsecure (1)");
 				return (ISC_R_SUCCESS);
 			}
 			return (startfinddlvsep(val, dns_rootname));
@@ -2769,7 +3021,7 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 				      "no supported algorithm/digest (%s/DS)",
 				      namebuf);
 			if (val->view->dlv == NULL || DLVTRIED(val)) {
-				markanswer(val);
+				markanswer(val, "proveunsecure (2)");
 				result = ISC_R_SUCCESS;
 				goto out;
 			}
@@ -2799,18 +3051,23 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 			      namebuf);
 
 		result = view_find(val, tname, dns_rdatatype_ds);
-
 		if (result == DNS_R_NXRRSET || result == DNS_R_NCACHENXRRSET) {
 			/*
 			 * There is no DS.  If this is a delegation,
 			 * we maybe done.
 			 */
-			if (DNS_TRUST_PENDING(val->frdataset.trust)) {
-				result = create_fetch(val, tname,
-						      dns_rdatatype_ds,
-						      dsfetched2,
-						      "proveunsecure");
-				if (result != ISC_R_SUCCESS)
+			/*
+			 * If we have "trust == answer" then this namespace
+			 * has switched from insecure to should be secure.
+			 */
+			if (DNS_TRUST_PENDING(val->frdataset.trust) ||
+			    DNS_TRUST_ANSWER(val->frdataset.trust)) {
+				result = create_validator(val, tname,
+							  dns_rdatatype_ds,
+							  &val->frdataset,
+							  NULL, dsvalidated,
+							  "proveunsecure");
+				 if (result != ISC_R_SUCCESS)
 					goto out;
 				return (DNS_R_WAIT);
 			}
@@ -2831,7 +3088,7 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 					return (DNS_R_MUSTBESECURE);
 				}
 				if (val->view->dlv == NULL || DLVTRIED(val)) {
-					markanswer(val);
+					markanswer(val, "proveunsecure (3)");
 					return (ISC_R_SUCCESS);
 				}
 				return (startfinddlvsep(val, tname));
@@ -2856,7 +3113,8 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 					}
 					if (val->view->dlv == NULL ||
 					    DLVTRIED(val)) {
-						markanswer(val);
+						markanswer(val,
+							   "proveunsecure (5)");
 						result = ISC_R_SUCCESS;
 						goto out;
 					}
@@ -2870,6 +3128,9 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 				result = DNS_R_NOVALIDSIG;
 				goto out;
 			}
+			/*
+			 * Validate / re-validate answer.
+			 */
 			result = create_validator(val, tname, dns_rdatatype_ds,
 						  &val->frdataset,
 						  &val->fsigrdataset,
@@ -2891,6 +3152,20 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 				 */
 				result = DNS_R_NOVALIDNSEC;
 				goto out;
+			} else if (DNS_TRUST_PENDING(val->frdataset.trust) ||
+				   DNS_TRUST_ANSWER(val->frdataset.trust)) {
+				/*
+				 * If we have "trust == answer" then this namespace
+				 * has switched from insecure to should be secure.
+				 */
+				result = create_validator(val, tname,
+							  dns_rdatatype_ds,
+							  &val->frdataset,
+							  NULL, dsvalidated,
+							  "proveunsecure");
+				if (result != ISC_R_SUCCESS)
+					goto out;
+				return (DNS_R_WAIT);
 			} else if (val->frdataset.trust < dns_trust_secure) {
 				/*
 				 * This shouldn't happen, since the negative
@@ -2914,8 +3189,10 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 		} else if (result == DNS_R_BROKENCHAIN)
 			return (result);
 	}
+
+	/* Couldn't complete insecurity proof */
 	validator_log(val, ISC_LOG_DEBUG(3), "insecurity proof failed");
-	return (DNS_R_NOTINSECURE); /* Couldn't complete insecurity proof */
+	return (DNS_R_NOTINSECURE);
 
  out:
 	if (dns_rdataset_isassociated(&val->frdataset))
@@ -3008,7 +3285,8 @@ validator_start(isc_task_t *task, isc_event_t *event) {
 			if (result == DNS_R_NOTINSECURE)
 				result = saved_result;
 		}
-	} else if (val->event->rdataset != NULL) {
+	} else if (val->event->rdataset != NULL &&
+		   val->event->rdataset->type != 0) {
 		/*
 		 * This is either an unsecure subdomain or a response from
 		 * a broken server.
@@ -3034,6 +3312,21 @@ validator_start(isc_task_t *task, isc_event_t *event) {
 		} else
 			val->attributes |= VALATTR_NEEDNODATA;
 		result = nsecvalidate(val, ISC_FALSE);
+	} else if (val->event->rdataset != NULL &&
+		    val->event->rdataset->type == 0)
+	{
+		/*
+		 * This is a nonexistence validation.
+		 */
+		validator_log(val, ISC_LOG_DEBUG(3),
+			      "attempting negative response validation");
+
+		if (val->event->rdataset->covers == dns_rdatatype_any) {
+			val->attributes |= VALATTR_NEEDNOQNAME;
+			val->attributes |= VALATTR_NEEDNOWILDCARD;
+		} else
+			val->attributes |= VALATTR_NEEDNODATA;
+		result = nsecvalidate(val, ISC_FALSE);
 	} else {
 		/*
 		 * This shouldn't happen.

lib/dns/win32/libdns.def

@@ -573,6 +573,7 @@ dns_tkey_processgssresponse
 dns_tkey_processquery
 dns_tkeyctx_create
 dns_tkeyctx_destroy
+dns_trust_totext
 dns_tsig_sign
 dns_tsig_verify
 dns_tsigkey_attach

lib/isc/api

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

lib/isc/print.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2008, 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: print.c,v 1.27.18.5 2008/02/18 23:46:01 tbox Exp $ */
+/* $Id: print.c,v 1.27.18.7 2010/10/18 23:45:45 tbox Exp $ */
 
 /*! \file */
 
@@ -468,7 +468,7 @@ isc_print_vsnprintf(char *str, size_t size, const char *format, va_list ap) {
 			if (width > 0) {
 				count += width;
 				width--;
-				if (left) {
+				if (left && size > 1) {
 					*str++ = c;
 					size--;
 				}

release-notes.css

@@ -0,0 +1,60 @@
+/*
+ * 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: release-notes.css,v 1.1.2.2 2010/11/29 01:15:44 tbox Exp $ */
+
+body {
+	background-color: #ffffff;
+	color: #333333;
+	font-family: "Helvetica Neue", "ArialMT", "Verdana", "Arial", "Helvetica", sans-serif;
+	font-size: 14px;
+	line-height: 18px;
+	margin: 2em auto;
+	width: 700px;
+}
+
+.command {
+	font-family: "Courier New", "Courier", monospace;
+	font-weight: normal;
+}
+
+.note {
+	background-color: #ddeedd;
+	border: 1px solid #aaccaa;
+	margin: 1em 0 1em 0;
+	padding: 0.5em 1em 0.5em 1em;
+	-moz-border-radius: 10px;
+	-webkit-border-radius: 10px;
+}
+
+.screen {
+	background-color: #ffffee;
+	border: 1px solid #ddddaa;
+	padding: 0.25em 1em 0.25em 1em;
+	margin: 1em 0 1em 0;
+	-moz-border-radius: 10px;
+	-webkit-border-radius: 10px;
+}
+
+.section.title {
+	font-size: 150%;
+	font-weight: bold;
+}
+
+.section.section.title {
+  font-size: 130%;
+  font-weight: bold;
+}

util/copyrights

@@ -6,6 +6,9 @@
 ./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,2010
 ./README.idnkit					X	2005,2009
+./RELEASE-NOTES-BIND-9.4-ESV.html		HTML	2010
+./RELEASE-NOTES-BIND-9.4-ESV.pdf		X	2010
+./RELEASE-NOTES-BIND-9.4-ESV.txt		X	2010
 ./acconfig.h					C	1999,2000,2001,2002,2003,2004,2005,2008
 ./aclocal.m4					X	1999,2000,2001
 ./bin/.cvsignore				X	1998,1999,2000,2001
@@ -135,7 +138,7 @@
 ./bin/named/named.docbook			SGML	2000,2001,2003,2004,2005,2006,2007,2008
 ./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/query.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
 ./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
@@ -452,7 +455,7 @@
 ./bin/tests/system/common/controls.conf		CONF-C	2000,2001,2004
 ./bin/tests/system/common/rndc.conf		CONF-C	2000,2001,2004
 ./bin/tests/system/common/root.hint		ZONE	2000,2001,2004
-./bin/tests/system/conf.sh.in			SH	2000,2001,2002,2003,2004,2005,2006,2008,2009
+./bin/tests/system/conf.sh.in			SH	2000,2001,2002,2003,2004,2005,2006,2008,2009,2010
 ./bin/tests/system/dialup/ns1/.cvsignore	X	2000,2001
 ./bin/tests/system/dialup/ns1/example.db	ZONE	2000,2001,2004
 ./bin/tests/system/dialup/ns1/named.conf	CONF-C	2000,2001,2004
@@ -466,42 +469,47 @@
 ./bin/tests/system/dialup/setup.sh		SH	2000,2001,2004
 ./bin/tests/system/dialup/tests.sh		SH	2000,2001,2004
 ./bin/tests/system/digcomp.pl			PERL	2000,2001,2004
-./bin/tests/system/dlv/clean.sh			SH	2004
+./bin/tests/system/dlv/clean.sh			SH	2004,2010
 ./bin/tests/system/dlv/ns1/named.conf		CONF-C	2004
 ./bin/tests/system/dlv/ns1/root.db		ZONE	2004
 ./bin/tests/system/dlv/ns1/rootservers.utld.db	ZONE	2004
 ./bin/tests/system/dlv/ns2/hints		ZONE	2004
 ./bin/tests/system/dlv/ns2/named.conf		CONF-C	2004
 ./bin/tests/system/dlv/ns2/utld.db		ZONE	2004
-./bin/tests/system/dlv/ns3/child.db.in		ZONE	2004
+./bin/tests/system/dlv/ns3/child.db.in		ZONE	2004,2010
 ./bin/tests/system/dlv/ns3/dlv.db.in		ZONE	2004
 ./bin/tests/system/dlv/ns3/hints		ZONE	2004
 ./bin/tests/system/dlv/ns3/named.conf		CONF-C	2004
-./bin/tests/system/dlv/ns3/sign.sh		SH	2004
+./bin/tests/system/dlv/ns3/sign.sh		SH	2004,2010
 ./bin/tests/system/dlv/ns4/child.db		ZONE	2004
 ./bin/tests/system/dlv/ns4/hints		ZONE	2004
 ./bin/tests/system/dlv/ns4/named.conf		CONF-C	2004
 ./bin/tests/system/dlv/ns5/hints		ZONE	2004
 ./bin/tests/system/dlv/ns5/named.conf		CONF-C	2004,2006,2007
 ./bin/tests/system/dlv/ns5/rndc.conf		CONF-C	2004
+./bin/tests/system/dlv/ns6/child.db.in		ZONE	2010
+./bin/tests/system/dlv/ns6/hints		ZONE	2010
+./bin/tests/system/dlv/ns6/named.conf		CONF-C	2010
+./bin/tests/system/dlv/ns6/sign.sh		SH	2010
 ./bin/tests/system/dlv/setup.sh			SH	2004
-./bin/tests/system/dlv/tests.sh			SH	2004
+./bin/tests/system/dlv/tests.sh			SH	2004,2010
 ./bin/tests/system/dnssec/README		TXT.BRIEF	2000,2001,2002,2004
 ./bin/tests/system/dnssec/clean.sh		SH	2000,2001,2002,2004,2005
 ./bin/tests/system/dnssec/dnssec_update_test.pl	PERL	2002,2004
 ./bin/tests/system/dnssec/ns1/.cvsignore	X	2000,2001
 ./bin/tests/system/dnssec/ns1/named.conf	CONF-C	2000,2001,2004,2006
-./bin/tests/system/dnssec/ns1/root.db.in	ZONE	2000,2001,2004
-./bin/tests/system/dnssec/ns1/sign.sh		SH	2000,2001,2002,2003,2004,2006
+./bin/tests/system/dnssec/ns1/root.db.in	ZONE	2000,2001,2004,2010
+./bin/tests/system/dnssec/ns1/sign.sh		SH	2000,2001,2002,2003,2004,2006,2010
 ./bin/tests/system/dnssec/ns2/.cvsignore	X	2000,2001
+./bin/tests/system/dnssec/ns2/algroll.db.in	ZONE	2010
 ./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,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/named.conf	CONF-C	2000,2001,2002,2004,2006,2010
 ./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,2009
+./bin/tests/system/dnssec/ns2/sign.sh		SH	2000,2001,2002,2003,2004,2006,2009,2010
 ./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 +526,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,2009
+./bin/tests/system/dnssec/tests.sh		SH	2000,2001,2002,2004,2005,2006,2009,2010
 ./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
@@ -663,14 +671,22 @@
 ./bin/tests/system/relay/setup.sh		SH	2000,2001,2004
 ./bin/tests/system/relay/tests.sh		SH	2000,2001,2004
 ./bin/tests/system/resolver/ans2/.cvsignore	X	2001
-./bin/tests/system/resolver/ans2/ans.pl		PERL	2000,2001,2004,2007
+./bin/tests/system/resolver/ans2/ans.pl		PERL	2000,2001,2004,2007,2010
 ./bin/tests/system/resolver/ans3/.cvsignore	X	2001
 ./bin/tests/system/resolver/ans3/ans.pl		PERL	2000,2001,2004,2007
+./bin/tests/system/resolver/clean.sh		SH	2010
 ./bin/tests/system/resolver/ns1/.cvsignore	X	2001
 ./bin/tests/system/resolver/ns1/named.conf	CONF-C	2000,2001,2004,2007
 ./bin/tests/system/resolver/ns1/root.hint	ZONE	2000,2001,2004
+./bin/tests/system/resolver/ns6/example.net.db.in	ZONE	2010
+./bin/tests/system/resolver/ns6/keygen.sh	SH	2010
+./bin/tests/system/resolver/ns6/named.conf	CONF-C	2010
+./bin/tests/system/resolver/ns6/root.db		ZONE	2010
+./bin/tests/system/resolver/ns7/named.conf	CONF-C	2010
+./bin/tests/system/resolver/ns7/root.hint	ZONE	2010
 ./bin/tests/system/resolver/prereq.sh		SH	2000,2001,2004
-./bin/tests/system/resolver/tests.sh		SH	2000,2001,2004
+./bin/tests/system/resolver/setup.sh		SH	2010
+./bin/tests/system/resolver/tests.sh		SH	2000,2001,2004,2010
 ./bin/tests/system/rrsetorder/clean.sh		SH	2006
 ./bin/tests/system/rrsetorder/dig.out.cyclic.good1	X	2006
 ./bin/tests/system/rrsetorder/dig.out.cyclic.good2	X	2006
@@ -746,7 +762,7 @@
 ./bin/tests/system/stub/ns3/example.db		ZONE	2000,2001,2004
 ./bin/tests/system/stub/ns3/named.conf		CONF-C	2000,2001,2004,2007
 ./bin/tests/system/stub/tests.sh		SH	2000,2001,2004
-./bin/tests/system/testsock.pl			PERL	2000,2001,2004
+./bin/tests/system/testsock.pl			PERL	2000,2001,2004,2010
 ./bin/tests/system/tkey/.cvsignore		X	2001
 ./bin/tests/system/tkey/Makefile.in		MAKE	2001,2002,2004
 ./bin/tests/system/tkey/clean.sh		SH	2001,2004
@@ -1226,8 +1242,8 @@
 ./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/isc-logo.eps				X	2005,2010
+./doc/arm/isc-logo.pdf				X	2005,2010
 ./doc/arm/latex-fixup.pl			PERL	2005
 ./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
@@ -1759,7 +1775,7 @@
 ./lib/dns/acache.c				C	2004,2005,2006,2008
 ./lib/dns/acl.c					C	1999,2000,2001,2002,2004,2005,2006
 ./lib/dns/adb.c					C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./lib/dns/api					X	1999,2000,2001,2005,2006,2007,2008,2009
+./lib/dns/api					X	1999,2000,2001,2005,2006,2007,2008,2009,2010
 ./lib/dns/byaddr.c				C	2000,2001,2002,2003,2004,2005
 ./lib/dns/cache.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2008,2009
 ./lib/dns/callbacks.c				C	1999,2000,2001,2004,2005
@@ -1799,7 +1815,7 @@
 ./lib/dns/include/dns/callbacks.h		C	1999,2000,2001,2002,2004,2005
 ./lib/dns/include/dns/cert.h			C	1999,2000,2001,2004,2005
 ./lib/dns/include/dns/compress.h		C	1999,2000,2001,2002,2004,2005,2006,2009
-./lib/dns/include/dns/db.h			C	1999,2000,2001,2002,2003,2004,2005,2007,2009
+./lib/dns/include/dns/db.h			C	1999,2000,2001,2002,2003,2004,2005,2007,2009,2010
 ./lib/dns/include/dns/dbiterator.h		C	1999,2000,2001,2004,2005
 ./lib/dns/include/dns/dbtable.h			C	1999,2000,2001,2004,2005
 ./lib/dns/include/dns/diff.h			C	2000,2001,2004,2005,2009
@@ -1821,7 +1837,7 @@
 ./lib/dns/include/dns/masterdump.h		C	1999,2000,2001,2002,2004,2005
 ./lib/dns/include/dns/message.h			C	1999,2000,2001,2002,2003,2004,2005,2006,2009
 ./lib/dns/include/dns/name.h			C	1998,1999,2000,2001,2002,2003,2004,2005,2006,2009
-./lib/dns/include/dns/ncache.h			C	1999,2000,2001,2002,2004,2005
+./lib/dns/include/dns/ncache.h			C	1999,2000,2001,2002,2004,2005,2010
 ./lib/dns/include/dns/nsec.h			C	1999,2000,2001,2003,2004,2005
 ./lib/dns/include/dns/opcode.h			C	2002,2004,2005
 ./lib/dns/include/dns/order.h			C	2002,2004,2005
@@ -1853,7 +1869,7 @@
 ./lib/dns/include/dns/tkey.h			C	1999,2000,2001,2004,2005,2009
 ./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/types.h			C	1998,1999,2000,2001,2002,2003,2004,2005,2006,2009,2010
 ./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
@@ -2044,7 +2060,7 @@
 ./lib/isc/alpha/include/isc/.cvsignore		X	2007
 ./lib/isc/alpha/include/isc/Makefile.in		MAKE	2007
 ./lib/isc/alpha/include/isc/atomic.h		C	2005,2009
-./lib/isc/api					X	1999,2000,2001,2005,2006,2007,2008,2009
+./lib/isc/api					X	1999,2000,2001,2005,2006,2007,2008,2009,2010
 ./lib/isc/assertions.c				C	1997,1998,1999,2000,2001,2004,2005,2008
 ./lib/isc/base64.c				C	1998,1999,2000,2001,2003,2004,2005
 ./lib/isc/bitstring.c				C	1999,2000,2001,2004,2005
@@ -2189,7 +2205,7 @@
 ./lib/isc/powerpc/include/isc/.cvsignore	X	2007
 ./lib/isc/powerpc/include/isc/Makefile.in	MAKE	2007
 ./lib/isc/powerpc/include/isc/atomic.h		C	2005,2007
-./lib/isc/print.c				C	1999,2000,2001,2003,2004,2005,2006,2008
+./lib/isc/print.c				C	1999,2000,2001,2003,2004,2005,2006,2008,2010
 ./lib/isc/pthreads/.cvsignore			X	1998,1999,2000,2001
 ./lib/isc/pthreads/Makefile.in			MAKE	1998,1999,2000,2001,2004
 ./lib/isc/pthreads/condition.c			C	1998,1999,2000,2001,2004,2005
@@ -2551,6 +2567,7 @@
 ./make/mkdep.in					X	1999,2000,2001
 ./make/rules.in					MAKE	1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
 ./mkinstalldirs					X	1996
+./release-notes.css				C	2010
 ./util/.cvsignore				X	2000,2001
 ./util/COPYRIGHT				X	1996,1997,1998,1999,2000,2001,2004
 ./util/COPYRIGHT.BRIEF				X	1996,1997,1998,1999,2000,2001,2004
@@ -2569,7 +2586,7 @@
 ./util/mandoc2docbook.pl			PERL	2001,2004
 ./util/mdnbuildtest.sh				SH	2000,2001,2004
 ./util/memleak.pl				PERL	1999,2000,2001,2004
-./util/merge_copyrights				PERL	1998,1999,2000,2001,2003,2004,2005,2006,2007,2009
+./util/merge_copyrights				PERL	1998,1999,2000,2001,2003,2004,2005,2006,2007,2009,2010
 ./util/mkreslib.pl				PERL	2000,2001,2004
 ./util/nanny.pl					PERL	2000,2001,2004
 ./util/nt-kit					SH	1999,2000,2001,2004
@@ -2578,7 +2595,7 @@
 ./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,2010
-./win32utils/BINDBuild.dsw			X	2001,2005,2006
+./win32utils/BINDBuild.dsw			X	2001,2005,2006,2010
 ./win32utils/BuildAll.bat			BAT	2001,2002,2004,2005,2006,2007
 ./win32utils/BuildOpenSSL.bat			BAT	2007
 ./win32utils/BuildPost.bat			BAT	2005,2006

util/merge_copyrights

@@ -1,6 +1,6 @@
 #!/usr/local/bin/perl -w
 #
-# Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2007, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001, 2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: merge_copyrights,v 1.19.18.12 2009/06/11 23:46:03 tbox Exp $
+# $Id: merge_copyrights,v 1.19.18.14 2010/11/17 23:45:12 tbox Exp $
 
 %file_types = ();
 %file_years = ();
@@ -72,7 +72,7 @@ while (<FILES>) {
 	    $file_types{$_} = "MAN";
 	} elsif ($base =~ /\/Makefile$/) {
 	    $file_types{$_} = "MAKE";
-	} elsif ($base =~ /\/(named|rndc).?\.conf$/) {
+	} elsif ($base =~ /\/(named|rndc).{0,2}\.conf$/) {
 	    $file_types{$_} = "CONF-C";
 	} elsif ($base =~ /\/resolv.?\.conf$/) {
 	    $file_types{$_} = "CONF-SH";

version

@@ -1,4 +1,4 @@
-# $Id: version,v 1.29.134.30 2010/05/10 01:56:40 marka Exp $
+# $Id: version,v 1.29.134.32.10.1 2011/05/26 23:56:25 each 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=-R2
+RELEASEVER=-R4-P1

win32utils/BINDBuild.dsw

@@ -48,6 +48,12 @@ Package=<4>
     Project_Dep_Name liblwres
     End Project Dependency
     Begin Project Dependency
+    Project_Dep_Name libisccfg
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name libisccc
+    End Project Dependency
+    Begin Project Dependency
     Project_Dep_Name dighost
     End Project Dependency
 }}}
@@ -185,6 +191,9 @@ Package=<5>
 
 Package=<4>
 {{{
+    Begin Project Dependency
+    Project_Dep_Name libdns
+    End Project Dependency
     Begin Project Dependency
     Project_Dep_Name libisc
     End Project Dependency
@@ -212,6 +221,9 @@ Package=<5>
 
 Package=<4>
 {{{
+    Begin Project Dependency
+    Project_Dep_Name libbind9
+    End Project Dependency
     Begin Project Dependency
     Project_Dep_Name libdns
     End Project Dependency
@@ -227,9 +239,6 @@ Package=<4>
     Begin Project Dependency
     Project_Dep_Name liblwres
     End Project Dependency
-    Begin Project Dependency
-    Project_Dep_Name libbind9
-    End Project Dependency
 }}}
 
 ###############################################################################
@@ -243,16 +252,19 @@ Package=<5>
 Package=<4>
 {{{
     Begin Project Dependency
-    Project_Dep_Name libisc
+    Project_Dep_Name checktool
     End Project Dependency
     Begin Project Dependency
-    Project_Dep_Name libisccfg
+    Project_Dep_Name bind9
     End Project Dependency
     Begin Project Dependency
     Project_Dep_Name libdns
     End Project Dependency
     Begin Project Dependency
-    Project_Dep_Name checktool
+    Project_Dep_Name libisc
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name libisccfg
     End Project Dependency
 }}}
 
@@ -266,6 +278,9 @@ Package=<5>
 
 Package=<4>
 {{{
+    Begin Project Dependency
+    Project_Dep_Name checktool
+    End Project Dependency
     Begin Project Dependency
     Project_Dep_Name libdns
     End Project Dependency
@@ -273,7 +288,7 @@ Package=<4>
     Project_Dep_Name libisc
     End Project Dependency
     Begin Project Dependency
-    Project_Dep_Name checktool
+    Project_Dep_Name libisccfg
     End Project Dependency
 }}}
 
@@ -287,6 +302,9 @@ Package=<5>
 
 Package=<4>
 {{{
+    Begin Project Dependency
+    Project_Dep_Name libbind9
+    End Project Dependency
     Begin Project Dependency
     Project_Dep_Name libdns
     End Project Dependency
@@ -294,9 +312,6 @@ Package=<4>
     Project_Dep_Name libisc
     End Project Dependency
     Begin Project Dependency
-    Project_Dep_Name libbind9
-    End Project Dependency
-    Begin Project Dependency
     Project_Dep_Name liblwres
     End Project Dependency
     Begin Project Dependency
@@ -314,6 +329,9 @@ Package=<5>
 
 Package=<4>
 {{{
+    Begin Project Dependency
+    Project_Dep_Name libbind9
+    End Project Dependency
     Begin Project Dependency
     Project_Dep_Name libdns
     End Project Dependency
@@ -321,7 +339,7 @@ Package=<4>
     Project_Dep_Name libisc
     End Project Dependency
     Begin Project Dependency
-    Project_Dep_Name libbind9
+    Project_Dep_Name liblwres
     End Project Dependency
 }}}
 
@@ -335,6 +353,12 @@ Package=<5>
 
 Package=<4>
 {{{
+    Begin Project Dependency
+    Project_Dep_Name libbind9
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name libdns
+    End Project Dependency
     Begin Project Dependency
     Project_Dep_Name libisc
     End Project Dependency
@@ -345,9 +369,6 @@ Package=<4>
     Project_Dep_Name libisccfg
     End Project Dependency
     Begin Project Dependency
-    Project_Dep_Name libbind9
-    End Project Dependency
-    Begin Project Dependency
     Project_Dep_Name rndcutil
     End Project Dependency
 }}}
@@ -362,6 +383,18 @@ Package=<5>
 
 Package=<4>
 {{{
+    Begin Project Dependency
+    Project_Dep_Name libdns
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name libisc
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name libisccc
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name libisccfg
+    End Project Dependency
     Begin Project Dependency
     Project_Dep_Name rndcutil
     End Project Dependency
@@ -377,15 +410,15 @@ Package=<5>
 
 Package=<4>
 {{{
+    Begin Project Dependency
+    Project_Dep_Name dnssectool
+    End Project Dependency
     Begin Project Dependency
     Project_Dep_Name libdns
     End Project Dependency
     Begin Project Dependency
     Project_Dep_Name libisc
     End Project Dependency
-    Begin Project Dependency
-    Project_Dep_Name dnssectool
-    End Project Dependency
 }}}
 
 ###############################################################################