This commit was manufactured by cvs2git to create branch 'rt22288_method2'.

update
update copyright notice
2010-11-29 02:15:07 +00:00 · 2010-11-29 02:15:06 +00:00 · 2010-11-29 01:15:44 +00:00 · 2010-11-29 01:11:04 +00:00 · 2010-11-29 00:41:03 +00:00 · 2010-11-29 00:40:13 +00:00
63 changed files with 11154 additions and 11988 deletions
@@ -1,3 +1,64 @@
+	--- 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
+			from unsigned zones. [RT #21131]
+
 	--- 9.4-ESV-R1 released ---

 2852.	[bug]		Handle broken DNSSEC trust chains better. [RT #15619]
@@ -0,0 +1,123 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<!--
+ - 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-BIND-9.4-ESV.html,v 1.1.2.2 2010/11/29 01:15:44 tbox Exp $ -->
+
+<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><link rel="stylesheet" type="text/css" href="release-notes.css" /><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /></head><body><div class="article"><div class="titlepage"><hr /></div>
+
+  <div class="section" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111797"></a>Introduction</h2></div></div></div>
+    
+    <p>
+			BIND 9.3-ESV-R4 is a maintenance release for BIND 9.4-ESV.
+		</p>
+    <p>
+			This document summarizes changes from BIND 9.4-ESV-R3 to BIND 9.4-ESV-R4.
+			Please see the CHANGES file in the source code release for a
+			complete list of all changes.
+		</p>
+  </div>
+
+  <div class="section" title="Download"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111880"></a>Download</h2></div></div></div>
+    
+    <p>
+			The latest release of BIND 9 software can always be found
+	 		on our web site at
+      <a class="ulink" href="http://www.isc.org/software/bind" target="_top">http://www.isc.org/software/bind</a>.
+  		There you will find additional information about each release,
+ 			source code, and some pre-compiled versions for certain operating
+ 			systems.
+		</p>
+  </div>
+
+  <div class="section" title="Support"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111815"></a>Support</h2></div></div></div>
+    
+    <p>Product support information is available on
+      <a class="ulink" href="http://www.isc.org/services/support" target="_top">http://www.isc.org/services/support</a>
+      for paid support options.  Free support is provided by our user
+ 			community via a mailing list.  Information on all public email
+ 			lists is available at
+      <a class="ulink" href="https://lists.isc.org/mailman/listinfo" target="_top">https://lists.isc.org/mailman/listinfo</a>.
+    </p>
+  </div>
+
+  <div class="section" title="New Features"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111957"></a>New Features</h2></div></div></div>
+    
+		<div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36111972"></a>9.4-ESV-R4</h3></div></div></div>
+			
+			<p>None.</p>
+		</div>
+  </div>
+
+  <div class="section" title="Feature Changes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111905"></a>Feature Changes</h2></div></div></div>
+    
+		<div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36111988"></a>9.4-ESV-R4</h3></div></div></div>
+			
+			<p>None.</p>
+		</div>
+  </div>
+
+  <div class="section" title="Security Fixes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36111999"></a>Security Fixes</h2></div></div></div>
+    
+		<div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36112004"></a>9.4-ESV-R4</h3></div></div></div>
+			
+			<div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
+				 	Adding a NO DATA signed negative response to cache failed to clear
+				  any matching RRSIG records already in cache. A subsequent lookup
+				  of the cached NO DATA entry could crash named (INSIST) when the
+				  unexpected RRSIG was also returned with the NO DATA cache entry.
+				  [RT #22288] [CVE-2010-3613] [VU#706148]
+				</li><li class="listitem">
+					BIND, acting as a DNSSEC validator, was determining if the NS RRset
+				  is insecure based on a value that could mean either that the RRset
+				  is actually insecure or that there wasn't a matching key for the RRSIG
+				  in the DNSKEY RRset when resuming from validating the DNSKEY RRset.
+				  This can happen when in the middle of a DNSKEY algorithm rollover,
+				  when two different algorithms were used to sign a zone but only the
+				  new set of keys are in the zone DNSKEY RRset.
+					[RT #22309] [CVE-2010-3614] [VU#837744]
+				</li></ul></div>
+		</div>
+  </div>
+
+  <div class="section" title="Bug Fixes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36112029"></a>Bug Fixes</h2></div></div></div>
+    
+		<div class="section" title="9.4-ESV-R4"><div class="titlepage"><div><div><h3 class="title"><a id="id36112035"></a>9.4-ESV-R4</h3></div></div></div>
+			
+	    <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">
+          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]
+				</li><li class="listitem">
+          win32: add more dependencies to BINDBuild.dsw.
+          [RT #22062]
+				</li></ul></div>
+		</div>
+  </div>
+
+  <div class="section" title="Thank You"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id36112054"></a>Thank You</h2></div></div></div>
+    
+    <p>
+      Thank you to everyone who assisted us in making this release possible.
+      If you would like to contribute to ISC to assist us in continuing to make
+      quality open source software, please visit our donations page at
+      <a class="ulink" href="http://www.isc.org/supportisc" target="_top">http://www.isc.org/supportisc</a>.
+    </p>
+  </div>
+</div></body></html>
@@ -0,0 +1,70 @@
+     __________________________________________________________________
+
+Introduction
+
+   BIND 9.3-ESV-R4 is a maintenance release for BIND 9.4-ESV.
+
+   This document summarizes changes from BIND 9.4-ESV-R3 to BIND
+   9.4-ESV-R4. Please see the CHANGES file in the source code release for
+   a complete list of all changes.
+
+Download
+
+   The latest release of BIND 9 software can always be found on our web
+   site at http://www.isc.org/software/bind. There you will find
+   additional information about each release, source code, and some
+   pre-compiled versions for certain operating systems.
+
+Support
+
+   Product support information is available on
+   http://www.isc.org/services/support for paid support options. Free
+   support is provided by our user community via a mailing list.
+   Information on all public email lists is available at
+   https://lists.isc.org/mailman/listinfo.
+
+New Features
+
+9.4-ESV-R4
+
+   None.
+
+Feature Changes
+
+9.4-ESV-R4
+
+   None.
+
+Security Fixes
+
+9.4-ESV-R4
+
+     * Adding a NO DATA signed negative response to cache failed to clear
+       any matching RRSIG records already in cache. A subsequent lookup of
+       the cached NO DATA entry could crash named (INSIST) when the
+       unexpected RRSIG was also returned with the NO DATA cache entry.
+       [RT #22288] [CVE-2010-3613] [VU#706148]
+     * BIND, acting as a DNSSEC validator, was determining if the NS RRset
+       is insecure based on a value that could mean either that the RRset
+       is actually insecure or that there wasn't a matching key for the
+       RRSIG in the DNSKEY RRset when resuming from validating the DNSKEY
+       RRset. This can happen when in the middle of a DNSKEY algorithm
+       rollover, when two different algorithms were used to sign a zone
+       but only the new set of keys are in the zone DNSKEY RRset. [RT
+       #22309] [CVE-2010-3614] [VU#837744]
+
+Bug Fixes
+
+9.4-ESV-R4
+
+     * 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]
+     * win32: add more dependencies to BINDBuild.dsw. [RT #22062]
+
+Thank You
+
+   Thank you to everyone who assisted us in making this release possible.
+   If you would like to contribute to ISC to assist us in continuing to
+   make quality open source software, please visit our donations page at
+   http://www.isc.org/supportisc.
@@ -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
@@ -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@
@@ -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,7 +14,7 @@
 # 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 2010/06/04 23:46:02 tbox Exp $

 rm -f random.data
 rm -f ns*/named.run
@@ -25,3 +25,11 @@ rm -f ns3/dlvset-*
 rm -f ns3/dsset-*
 rm -f ns3/keyset-*
 rm -f ns3/trusted.conf ns5/trusted.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*
@@ -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
@@ -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,7 +14,9 @@
 # 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 2010/06/04 23:46:02 tbox Exp $
+
+(cd ../ns6 && sh -e sign.sh)

 SYSTEMTESTTOP=../..
 . $SYSTEMTESTTOP/conf.sh
@@ -29,12 +31,12 @@ 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"


@@ -45,12 +47,12 @@ 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"


@@ -61,12 +63,12 @@ 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"


@@ -77,12 +79,12 @@ 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"


@@ -92,12 +94,12 @@ 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"


@@ -107,12 +109,12 @@ 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"


@@ -123,12 +125,12 @@ 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.
@@ -138,12 +140,12 @@ 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 >$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"


@@ -153,12 +155,12 @@ 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"


@@ -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
@@ -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
@@ -0,0 +1,42 @@
+/*
+ * 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 2010/06/04 23:46:02 tbox 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"; };
@@ -0,0 +1,139 @@
+#!/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 2010/06/04 23:46:02 tbox Exp $
+
+SYSTEMTESTTOP=../..
+. $SYSTEMTESTTOP/conf.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"
@@ -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,33 @@
 # 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 2010/06/04 23:46:02 tbox 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:exit status: $status"
+exit $status
@@ -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
@@ -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.

@@ -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
@@ -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";
@@ -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
@@ -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.

@@ -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"));
@@ -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
@@ -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
@@ -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
@@ -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; };
+};
@@ -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
@@ -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";
+};
@@ -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
@@ -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)
@@ -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
@@ -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) {
@@ -2,22 +2,23 @@



-
 DNS Extensions Working Group                                Edward Lewis
 Internet-Draft                                             NeuStar, Inc.
 Updates: 1034, 1035 (if approved)                         A. Hoenes, Ed.
 Intended status: Standards Track                                  TR-Sys
-Expires: July 18, 2010                                  January 18, 2010
+Expires: September 26, 2010                               March 26, 2010


                    DNS Zone Transfer Protocol (AXFR)
-                    draft-ietf-dnsext-axfr-clarify-13
+                    draft-ietf-dnsext-axfr-clarify-14

 Abstract

-   The Domain Name System standard mechanisms for maintaining coherent
-   servers for a zone consist of three elements.  One mechanism is the
-   Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035.
+   The standard means within the Domain Name System protocol for
+   maintaining coherence among a zone's authoritative name servers
+   consists of three mechanisms.  Authoritative Transfer (AXFR) is one
+   of the mechanisms and is defined in RFC 1034 and RFC 1035.
+
   The definition of AXFR has proven insufficient in detail, thereby
   forcing implementations intended to be compliant to make assumptions,
   impeding interoperability.  Yet today we have a satisfactory set of
@@ -28,7 +29,7 @@ Abstract
 Status of this Memo

   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79. This document may contain material
+   provisions of BCP 78 and BCP 79.  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
@@ -54,16 +55,15 @@ Status of this Memo
   http://www.ietf.org/1id-abstracts.html


-
-Lewis & Hoenes            Expires July 18, 2010                 [Page 1]
+Lewis & Hoenes         Expires September 26, 2010               [Page 1]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

-   This Internet-Draft will expire on July 18, 2010.
+   This Internet-Draft will expire on September 26, 2010.

 Copyright Notice

@@ -111,9 +111,9 @@ Copyright Notice



-Lewis & Hoenes            Expires July 18, 2010                 [Page 2]
+Lewis & Hoenes         Expires September 26, 2010               [Page 2]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 Table of Contents
@@ -157,9 +157,9 @@ Table of Contents
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 25
   10.  Internationalization Considerations . . . . . . . . . . . . 25
   11.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
-   12.  References  . . . . . . . . . . . . . . . . . . . . . . . . 25
+   12.  References  . . . . . . . . . . . . . . . . . . . . . . . . 26
   12.1.  Normative References  . ..  . . . . . . . . . . . . . . . 26
-   12.2.  Informative References  . . . . . . . . . . . . . . . . . 27
+   12.2.  Informative References  . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28


@@ -167,9 +167,9 @@ Table of Contents



-Lewis & Hoenes            Expires July 18, 2010                 [Page 3]
+Lewis & Hoenes         Expires September 26, 2010               [Page 3]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 1.  Introduction
@@ -223,9 +223,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   data stored in relational databases (as opposed to master files),


-Lewis & Hoenes            Expires July 18, 2010                 [Page 4]
+Lewis & Hoenes         Expires September 26, 2010               [Page 4]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   relying on the database's non-DNS means to synchronize the database
@@ -279,9 +279,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   AXFR.


-Lewis & Hoenes            Expires July 18, 2010                 [Page 5]
+Lewis & Hoenes         Expires September 26, 2010               [Page 5]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   This document will update the specification of AXFR.  To this end, it
@@ -291,7 +291,8 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   4.2.2 of RFC 1035.  Furthermore, it discusses backward compatibility
   issues and provides policy/management considerations as well as
   specific Security Considerations for AXFR.  The goal of this document
-   is to define AXFR as it exists, or is supposed to exist, currently.
+   is to define AXFR as it is understood by the DNS community to exist
+   today.



@@ -334,10 +335,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-
-Lewis & Hoenes            Expires July 18, 2010                 [Page 6]
+Lewis & Hoenes         Expires September 26, 2010               [Page 6]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 2.  AXFR Messages
@@ -385,15 +385,15 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   -  "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]

   These documents contain information about the syntax and semantics of
-   DNS messages.  They ought not interfere with AXFR but are also
-   helpful in understanding what will be carried via AXFR.
+   DNS messages.  They do not interfere with AXFR but are also helpful
+   in understanding what will be carried via AXFR.




-Lewis & Hoenes            Expires July 18, 2010                 [Page 7]
+Lewis & Hoenes         Expires September 26, 2010               [Page 7]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   For convenience, the synopsis of the DNS message header from
@@ -447,9 +447,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                 [Page 8]
+Lewis & Hoenes         Expires September 26, 2010               [Page 8]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 2.1.1.  Header Values
@@ -503,20 +503,20 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                 [Page 9]
+Lewis & Hoenes         Expires September 26, 2010               [Page 9]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   d) The client MUST set this field to the number of resource records
-      it places into the Additional section.  In the absense of explicit
+      it places into the Additional section.  In the absence of explicit
      specification of new RRs to be carried in the Additional section
      of AXFR queries, the value MAY be 0, 1 or 2.  See Section 2.1.5
      "Additional Section" for details on the currently applicable RRs.

 2.1.2.  Question Section

-   The Question Section of the AXFR query MUST conform to Section 4.1.2
+   The Question section of the AXFR query MUST conform to Section 4.1.2
   of RFC 1035, and contain a single resource record with the following
   values:

@@ -543,25 +543,25 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   carried in the Additional section of normal DNS transactions need to
   explicitly describe their use with AXFR, should that be desired.

-   The client MAY include one EDNS0 OPT [RFC2671] resource record.  If
+   The client MAY include one OPT resource record [RFC2671].  If
   the server does not support EDNS0, the client MUST send this section
-   without an EDNS0 OPT resource record if there is a retry.  However,
+   without an OPT resource record if there is a retry.  However,
   the protocol does not define an explicit indication that the server
   does not support EDNS0; that needs to be inferred by the client.
   Often, the server will return a FormErr(1) which might be related to
   the OPT resource record.  Note that, at the time of this writing,
-   only the EXTENDED-RCODE field of the EDNS0 OPT RR is meaningful in
-   the context of AXFR; future specifications of EDNS0 flags and/or
-   EDNS0 options must describe their usage in the context of AXFR, if
+   only the EXTENDED-RCODE field of the OPT RR is meaningful in
+   the context of AXFR; future specifications of EDNS flags and/or
+   EDNS options must describe their usage in the context of AXFR, if
   applicable.

   The client MAY include one transaction integrity and authentication
   resource record, currently a choice of TSIG [RFC2845] or SIG(0)


-Lewis & Hoenes            Expires July 18, 2010                [Page 10]
+Lewis & Hoenes         Expires September 26, 2010              [Page 10]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   [RFC2931].  If the server has indicated that it does not recognize
@@ -578,7 +578,7 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010

   The range of permissible resource records that MAY appear in the
   Additional section might change over time.  If either a change to an
-   existing resource record (like the OPT RR for EDNS0) is made or a new
+   existing resource record (like the OPT RR for EDNS) is made or a new
   Additional section record is created, the new definitions ought to
   include a discussion on the applicability and impact upon AXFR.
   Future resource records residing in the Additional section might have
@@ -615,9 +615,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   AXFR clients MUST ignore any duplicate RRs received.


-Lewis & Hoenes            Expires July 18, 2010                [Page 11]
+Lewis & Hoenes         Expires September 26, 2010              [Page 11]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   Each AXFR response message SHOULD contain a sufficient number of RRs
@@ -671,9 +671,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
      NSCOUNT     MUST be 0


-Lewis & Hoenes            Expires July 18, 2010                [Page 12]
+Lewis & Hoenes         Expires September 26, 2010              [Page 12]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


      ARCOUNT     See Note g)
@@ -721,15 +721,15 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
      (Reminder, consult the appropriate IANA registry [DNSVALS].)  If a
      client receives any other value in response, it MUST act according
      to the error.  For example, a malformed AXFR query or the presence
-      of an EDNS0 OPT resource record sent to an old server will result
+      of an OPT resource record sent to an old server will result
      in a FormErr(1) value.  This value is not set as part of the AXFR-
      specific response processing.  The same is true for other values
      indicating an error.


-Lewis & Hoenes            Expires July 18, 2010                [Page 13]
+Lewis & Hoenes         Expires September 26, 2010              [Page 13]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   f) The count of answer records MUST equal the number of resource
@@ -739,7 +739,7 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
      client's limitations via configuration data.

   g) The server MUST set this field to the number of resource records
-      it places into the Additional section.  In the absense of explicit
+      it places into the Additional section.  In the absence of explicit
      specification of new RRs to be carried in the Additional section
      of AXFR response messages, the value MAY be 0, 1 or 2.  See
      Section 2.1.5 above for details on the currently applicable RRs
@@ -766,16 +766,16 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010

 2.2.5.  Additional Section

-   The contents of this section MUST follow the guidelines for EDNS0 and
-   TSIG, SIG(0), or whatever other future record is possible here.  The
-   contents of Section 2.1.5 apply analogously as well.
+   The contents of this section MUST follow the guidelines for the OPT,
+   TSIG, and SIG(0) RRs, or whatever other future record is possible
+   here.  The contents of Section 2.1.5 apply analogously as well.

   The following considerations specifically apply to AXFR responses:

-   If the client has supplied an EDNS0 OPT RR in the AXFR query and if
-   the server supports ENDS0 as well, it SHOULD include one EDNS0 OPT RR
+   If the client has supplied an EDNS OPT RR in the AXFR query and if
+   the server supports EDNS as well, it SHOULD include one OPT RR
   in the first response message and MAY do so in subsequent response
-   messages (see Section 2.2); the specifications of EDNS0 options to be
+   messages (see Section 2.2); the specifications of EDNS options to be
   carried in the OPT RR may impose stronger requirements.

   If the client has supplied a transaction security resource record
@@ -783,9 +783,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   method chosen by the client, it MUST place the corresponding resource


-Lewis & Hoenes            Expires July 18, 2010                [Page 14]
+Lewis & Hoenes         Expires September 26, 2010              [Page 14]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   record into the AXFR response message(s), according to the rules
@@ -839,9 +839,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   in Section 6 of RFC 2181.


-Lewis & Hoenes            Expires July 18, 2010                [Page 15]
+Lewis & Hoenes         Expires September 26, 2010              [Page 15]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   Zones for which it is impractical to list the entire zone for a
@@ -895,9 +895,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
      single zone.


-Lewis & Hoenes            Expires July 18, 2010                [Page 16]
+Lewis & Hoenes         Expires September 26, 2010              [Page 16]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   o  Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
@@ -951,9 +951,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   more authoritative set, concealing the error.)


-Lewis & Hoenes            Expires July 18, 2010                [Page 17]
+Lewis & Hoenes         Expires September 26, 2010              [Page 17]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   3) The inconsistent NS resource record set might indicate a problem
@@ -1007,9 +1007,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                [Page 18]
+Lewis & Hoenes         Expires September 26, 2010              [Page 18]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   Since the primary objective of AXFR is to enable the client to serve
@@ -1063,9 +1063,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                [Page 19]
+Lewis & Hoenes         Expires September 26, 2010              [Page 19]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   Therefore, the assumption that a TCP connection is dedicated to a
@@ -1091,7 +1091,7 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   In the original definition there arguably is an implicit assumption
   (probably unintentional) that a TCP connection is used for one and
   only one AXFR session.  This is evidenced in the lack of an explicit
-   requirement to copy the Question Section and/or the message ID into
+   requirement to copy the Question section and/or the message ID into
   responses, no explicit ordering information within the AXFR response
   messages, and the lack of an explicit notice indicating that a zone
   transfer continues in the next message.
@@ -1119,9 +1119,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   "apparent need".


-Lewis & Hoenes            Expires July 18, 2010                [Page 20]
+Lewis & Hoenes         Expires September 26, 2010              [Page 20]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


   An AXFR client can cancel the delivery of a zone only by closing the
@@ -1175,9 +1175,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   connection broken.


-Lewis & Hoenes            Expires July 18, 2010                [Page 21]
+Lewis & Hoenes         Expires September 26, 2010              [Page 21]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 4.2.  UDP
@@ -1231,9 +1231,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                [Page 22]
+Lewis & Hoenes         Expires September 26, 2010              [Page 22]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 6.  Zone Integrity
@@ -1287,9 +1287,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                [Page 23]
+Lewis & Hoenes         Expires September 26, 2010              [Page 23]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 7.  Backwards Compatibility
@@ -1343,13 +1343,19 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010



-Lewis & Hoenes            Expires July 18, 2010                [Page 24]
+Lewis & Hoenes         Expires September 26, 2010              [Page 24]

-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010


 8.  Security Considerations

+   This document is a clarification of a mechanism outlined in RFCs 1034
+   and 1035 and as such does not add any new security considerations.
+   RFC 3833 [RFC3833] is devoted entirely to security considerations for
+   the DNS; its Section 4.3 delineates zone transfer security aspects
+   from the security threats addressed by DNSSEC.
+
   Concerns regarding authorization, traffic flooding, and message
   integrity are mentioned in "Authorization" (Section 5), "TCP"
   (Section 4.2) and "Zone Integrity" (Section 6).
@@ -1357,8 +1363,9 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010

 9.  IANA Considerations

-   [[ Note to RFC-Ed: this section may be deleted before publication. ]]
-   No new registries or new registrations are included in this document.
+   IANA has added a reference to this RFC in the AXFR (252) row of the
+   "Resource Record (RR) TYPEs" subregistry of the "Domain Name System
+   (DNS) Parameters" registry.


 10.  Internationalization Considerations
@@ -1389,6 +1396,14 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   Edward Lewis served as a patiently listening sole document editor for
   two years.

+
+
+
+Lewis & Hoenes         Expires September 26, 2010              [Page 25]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
+
+
 12.  References

   All "RFC" references by can be obtained from the RFC Editor web site
@@ -1397,13 +1412,6 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   information regarding this organization can be found at the following
   URL:               http://rfc-editor.org/

-
-
-Lewis & Hoenes            Expires July 18, 2010                [Page 25]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
-
-
 12.1.  Normative References

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
@@ -1443,6 +1451,15 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
              RFC 2672, August 1999.

+
+
+
+
+Lewis & Hoenes         Expires September 26, 2010              [Page 26]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
+
+
   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.
@@ -1453,13 +1470,6 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
              ( SIG(0)s )", RFC 2931, September 2000.

-
-
-Lewis & Hoenes            Expires July 18, 2010                [Page 26]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
-
-
   [RFC3425]  Lawrence, D., "Obsoleting IQUERY", RFC 3425,
              November 2002.

@@ -1496,6 +1506,16 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
              and RRSIG Resource Records for DNSSEC", RFC 5702,
              October 2009.

+
+
+
+
+
+Lewis & Hoenes         Expires September 26, 2010              [Page 27]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)         March 2010
+
+
 12.2.  Informative References

   [DNSVALS]  IANA Registry "Domain Name System (DNS) Parameters",
@@ -1508,22 +1528,17 @@ Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
              Malis, "A Framework for IP Based Virtual Private
              Networks", RFC 2764, February 2000.

-
-
-
-Lewis & Hoenes            Expires July 18, 2010                [Page 27]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
-
-
   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

+   [RFC3833]  Atkins, D., and R. Austein, "Threat Analysis of the Domain
+              Name System (DNS)", RFC 3833, August 2004.
+
   [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
              Implementation Notes for DNSSECbis",
-              draft-ietf-dnsext-dnssec-bis-updates-09 (work in
-              progress), September 2009.
+              draft-ietf-dnsext-dnssec-bis-updates-10 (work in
+              progress), March 2010.


 Authors' Addresses
@@ -1552,20 +1567,5 @@ Editorial Note: Discussion  [[ to be removed by RFC-Editor ]]



-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes            Expires July 18, 2010                [Page 28]
+Lewis & Hoenes         Expires September 26, 2010              [Page 28]

@@ -3,14 +3,14 @@

 DNSEXT                                                         R. Bellis
 Internet-Draft                                                Nominet UK
-Updates: 1035, 1123                                      January 6, 2010
+Updates: 1035, 1123                                       March 22, 2010
 (if approved)
 Intended status: Standards Track
-Expires: July 10, 2010
+Expires: September 23, 2010


          DNS Transport over TCP - Implementation Requirements
-               draft-ietf-dnsext-dns-tcp-requirements-02
+               draft-ietf-dnsext-dns-tcp-requirements-03

 Abstract

@@ -38,7 +38,7 @@ Status of this Memo
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

-   This Internet-Draft will expire on July 10, 2010.
+   This Internet-Draft will expire on September 23, 2010.

 Copyright Notice

@@ -52,9 +52,9 @@ Copyright Notice



-Bellis                    Expires July 10, 2010                 [Page 1]
+Bellis                 Expires September 23, 2010               [Page 1]

-Internet-Draft                DNS over TCP                  January 2010
+Internet-Draft                DNS over TCP                    March 2010


   carefully, as they describe your rights and restrictions with respect
@@ -82,9 +82,11 @@ Table of Contents

   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7

-   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
-     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
+
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 7
+     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7

   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 8

@@ -106,19 +108,17 @@ Table of Contents



-
-
-Bellis                    Expires July 10, 2010                 [Page 2]
+Bellis                 Expires September 23, 2010               [Page 2]

-Internet-Draft                DNS over TCP                  January 2010
+Internet-Draft                DNS over TCP                    March 2010


 1.  Introduction

-   Most DNS [RFC1035] transactions take place over UDP [RFC0792].  The
-   TCP [RFC0793] is used for zone transfers and for the transfer of
-   other packets which exceed the protocol's original 512 byte packet-
-   size limit.
+   Most DNS [RFC1035] transactions take place over UDP [RFC0768].  TCP
+   [RFC0793] is always used for zone transfers and is often used for
+   messages whose sizes exceed the DNS protocol's original 512 byte
+   limit.

   Section 6.1.3.2 of [RFC1123] states:

@@ -141,7 +141,7 @@ Internet-Draft                DNS over TCP                  January 2010
   Whilst this document makes no specific recommendations to operators
   of DNS servers, it should be noted that failure to support TCP (or
   blocking of DNS over TCP at the network layer) may result in
-   resolution failure and application-level timeouts.
+   resolution failure and/or application-level timeouts.


 2.  Terminology used in this document
@@ -154,9 +154,9 @@ Internet-Draft                DNS over TCP                  January 2010
 3.  Discussion

   In the absence of EDNS0 (see below) the normal behaviour of any DNS
-   server needing to send a UDP response that exceeds that 512 byte
+   server needing to send a UDP response that would exceed the 512 byte
   limit is for the server to truncate the response so that it fits
-   within the 512 byte limit and set the TC flag in the response header.
+   within that limit and then set the TC flag in the response header.
   When the client receives such a response it takes the TC flag as an
   indication that it should retry over TCP instead.

@@ -164,9 +164,9 @@ Internet-Draft                DNS over TCP                  January 2010



-Bellis                    Expires July 10, 2010                 [Page 3]
+Bellis                 Expires September 23, 2010               [Page 3]

-Internet-Draft                DNS over TCP                  January 2010
+Internet-Draft                DNS over TCP                    March 2010



@@ -180,12 +180,12 @@ Internet-Draft                DNS over TCP                  January 2010
   Existing deployments of DNSSEC [RFC4033] have shown that truncation
   at the 512 byte boundary is now commonplace.  For example an NXDOMAIN
   (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155]
-   is almost invariably longer than 512 bytes.
+   is almost invariably larger than 512 bytes.

   Since the original core specifications for DNS were written, the
   Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
   These extensions can be used to indicate that the client is prepared
-   to receive UDP responses longer than 512 bytes.  An EDNS0 compatible
+   to receive UDP responses larger than 512 bytes.  An EDNS0 compatible
   server receiving a request from an EDNS0 compatible client may send
   UDP packets up to that client's announced buffer size without
   truncation.
@@ -193,9 +193,9 @@ Internet-Draft                DNS over TCP                  January 2010
   However, transport of UDP packets that exceed the size of the path
   MTU causes IP packet fragmentation, which has been found to be
   unreliable in some circumstances.  Many firewalls routinely block
-   fragmented IP packets, and some implementations lack the software
-   logic necessary to reassemble a fragmented datagram.  Worse still,
-   some devices deliberately refuse to handle DNS packets containing
+   fragmented IP packets, and some do not implement the algorithms
+   necessary to reassemble fragmented packets.  Worse still, some
+   network devices deliberately refuse to handle DNS packets containing
   EDNS0 options.  Other issues relating to UDP transport and packet
   size are discussed in [RFC5625].

@@ -210,28 +210,28 @@ Internet-Draft                DNS over TCP                  January 2010

 4.  Transport Protocol Selection

-   All DNS implementations MUST support both UDP and TCP transport.
+   All general purpose DNS implementations MUST support both UDP and TCP
+   transport.

-   o  Authoritative resolver implementations MUST support TCP so that
-      they may serve any long responses that they are configured to
-      serve.
+   o  Authoritative server implementations MUST support TCP so that they
+      do not limit the size of responses.





-Bellis                    Expires July 10, 2010                 [Page 4]
+Bellis                 Expires September 23, 2010               [Page 4]

-Internet-Draft                DNS over TCP                  January 2010
+Internet-Draft                DNS over TCP                    March 2010


-   o  A recursive resolver or forwarder MUST support TCP so that it does
-      not prevent long responses from a TCP-capable server from reaching
-      its TCP-capable clients.
-   o  A general purpose stub resolver implementation (e.g. an operating
-      system's DNS resolution library) MUST support TCP since to do
-      otherwise would limit its interoperability with its own clients
-      and with upstream servers.
+   o  Recursive resolver (or forwarder) implementations MUST support TCP
+      so that the do not prevent large responses from a TCP-capable
+      server from reaching its TCP-capable clients.
+   o  Stub resolver implementations (e.g. an operating system's DNS
+      resolution library) MUST support TCP since to do otherwise would
+      limit their interoperability with their own clients and with
+      upstream servers.

   An exception may be made for proprietary stub resolver
   implementations.  These MAY omit support for TCP if operating in an
@@ -256,7 +256,11 @@ Internet-Draft                DNS over TCP                  January 2010

      If the server needs to close a dormant connection to reclaim
      resources, it should wait until the connection has been idle for a
-      period on the order of two minutes.
+      period on the order of two minutes.  In particular, the server
+      should allow the SOA and AXFR request sequence (which begins a
+      refresh operation) to be made on a single connection.  Since the
+      server would be unable to answer queries anyway, a unilateral
+      close or reset may be used instead of a graceful close.

   Other more modern protocols (e.g.  HTTP [RFC2616]) have support for
   persistent TCP connections and operational experience has shown that
@@ -264,30 +268,28 @@ Internet-Draft                DNS over TCP                  January 2010
   under heavy load.  Intentionally opening many connections and leaving
   them dormant can trivially create a "denial of service" attack.

-   This document therefore RECOMMENDS that the application-level idle
-   period should be of the order of TBD seconds.
-
-   Servers MAY allow dormant connections to remain open for longer
-   periods, but for the avoidance of doubt persistent DNS connections
-   should generally be considered to be as much for the server's benefit
-   as for the client's.  Therefore if the server needs to unilaterally
-   close a dormant TCP connection it MUST be free to do so whenever
-   required.
+   This document therefore RECOMMENDS that the default application-level
+   idle period should be of the order of seconds, but does not specify
+   any particular value.  In practise the idle period may vary
+   dynamically, and servers MAY allow dormant connections to remain open
+   for longer periods as resources permit.



-Bellis                    Expires July 10, 2010                 [Page 5]
+Bellis                 Expires September 23, 2010               [Page 5]

-Internet-Draft                DNS over TCP                  January 2010
+Internet-Draft                DNS over TCP                    March 2010


-   To mitigate the risk of unintentional server overload DNS clients
+   To mitigate the risk of unintentional server overload, DNS clients
   MUST take care to minimize the number of concurrent TCP connections
-   made to any individual server.
+   made to any individual server.  Similarly servers MAY impose limits
+   on the number of concurrent TCP connections being handled for any
+   particular client.

-   Further recommendations for the tuning of TCP parameters to allow
-   higher throughput or improved resiliency against denial of service
-   attacks are outside the scope of this document.
+   Further recommendations for the tuning of TCP stacks to allow higher
+   throughput or improved resiliency against denial of service attacks
+   are outside the scope of this document.


 6.  Response re-ordering
@@ -309,45 +311,55 @@ Internet-Draft                DNS over TCP                  January 2010
 7.  Security Considerations

   Some DNS server operators have expressed concern that wider use of
-   DNS over TCP will expose them to a higher risk of "denial of service"
+   DNS over TCP will expose them to a higher risk of denial of service
   (DoS) attacks.

-   Whilst there is a theoretically higher risk of such attacks against
-   TCP-enabled servers, techniques for the mitigation of DoS attacks at
-   the network level have improved substantially since DNS was first
-   designed.
+   Although there is a higher risk of such attacks against TCP-enabled
+   servers, techniques for the mitigation of DoS attacks at the network
+   level have improved substantially since DNS was first designed.

-   The vast majority of TLD authority servers and all but one of the
-   root name servers already support TCP and the author knows of no
+   At the time of writing the vast majority of TLD authority servers and
+   all of the root name servers support TCP and the author knows of no
   evidence to suggest that TCP-based DoS attacks against existing DNS
   infrastructure are commonplace.

+   That notwithstanding, readers are advised to familiarise themselves
+   with [CPNI-TCP].
+
   Operators of recursive servers should ensure that they only accept
   connections from expected clients, and do not accept them from
-   unknown sources.  In the case of UDP traffic this will protect
+   unknown sources.  In the case of UDP traffic this will help protect
+
+
+
+Bellis                 Expires September 23, 2010               [Page 6]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
   against reflector attacks [RFC5358] and in the case of TCP traffic it
   will prevent an unknown client from exhausting the server's limits on
   the number of concurrent connections.


-
-
-Bellis                    Expires July 10, 2010                 [Page 6]
-
-Internet-Draft                DNS over TCP                  January 2010
-
-
 8.  IANA Considerations

   This document requests no IANA actions.


-9.  References
+9.  Acknowledgements

-9.1.  Normative References
+   The author would like to thank the document reviewers from the DNSEXT
+   Working Group, and in particular George Barwood, Alex Bligh, Alfred
+   Hoenes, Fernando Gont, Jim Reid, Paul Vixie and Nicholas Weaver.

-   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
-              RFC 792, September 1981.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.
@@ -364,10 +376,23 @@ Internet-Draft                DNS over TCP                  January 2010
   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

-9.2.  Informative References
+10.2.  Informative References
+
+   [CPNI-TCP]
+              CPNI, "Security Assessment of the Transmission Control
+              Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
+              tn-03-09-security-assessment-TCP.pdf>.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+
+
+
+Bellis                 Expires September 23, 2010               [Page 7]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
@@ -386,17 +411,18 @@ Internet-Draft                DNS over TCP                  January 2010
              BCP 152, RFC 5625, August 2009.


-
-
-Bellis                    Expires July 10, 2010                 [Page 7]
-
-Internet-Draft                DNS over TCP                  January 2010
-
-
 Appendix A.  Change Log

   NB: to be removed by the RFC Editor before publication.

+   draft-ietf-dnsext-dns-tcp-requirements-03
+      Editorial nits from WGLC
+      Clarification on "general purpose"
+      Fixed ref to UDP (RFC 768)
+      Included more S.4.2.2 text from RFC 1035 and removed some from
+      this draft relating to connection resets.
+      s/long/large/ for packet sizes
+
   draft-ietf-dnsext-dns-tcp-requirements-02
      Change of title - more focus on implementation and not operation
      Re-write of some of the security section
@@ -411,6 +437,18 @@ Appendix A.  Change Log
      Initial draft


+
+
+
+
+
+
+
+Bellis                 Expires September 23, 2010               [Page 8]
+
+Internet-Draft                DNS over TCP                    March 2010
+
+
 Author's Address

   Ray Bellis
@@ -444,5 +482,23 @@ Author's Address



-Bellis                    Expires July 10, 2010                 [Page 8]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                 Expires September 23, 2010               [Page 9]

@@ -5,60 +5,56 @@ Network Working Group                                          S. Weiler
 Internet-Draft                                              SPARTA, Inc.
 Updates: 4033, 4034, 4035, 5155                                D. Blacka
 (if approved)                                             VeriSign, Inc.
-Intended status: Standards Track                       September 5, 2009
-Expires: March 9, 2010
+Intended status: Standards Track                       November 10, 2010
+Expires: May 14, 2011


         Clarifications and Implementation Notes for DNSSECbis
-                draft-ietf-dnsext-dnssec-bis-updates-09
+                draft-ietf-dnsext-dnssec-bis-updates-12
+
+Abstract
+
+   This document is a collection of technical clarifications to the
+   DNSSECbis document set.  It is meant to serve as a resource to
+   implementors as well as a repository of DNSSECbis errata.

 Status of this Memo

-   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 March 9, 2010.
+   This Internet-Draft will expire on May 14, 2011.

 Copyright Notice

-   Copyright (c) 2009 IETF Trust and the persons identified as the
+   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   This document is a collection of technical clarifications to the
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   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.



-Weiler & Blacka           Expires March 9, 2010                 [Page 1]
+Weiler & Blacka           Expires May 14, 2011                  [Page 1]

-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
-   DNSSECbis document set.  It is meant to serve as a resource to
-   implementors as well as a repository of DNSSECbis errata.
+Internet-Draft       DNSSECbis Implementation Notes        November 2010


 Table of Contents
@@ -68,34 +64,40 @@ Table of Contents
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Important Additions to DNSSSECbis  . . . . . . . . . . . . . .  3
     2.1.  NSEC3 Support  . . . . . . . . . . . . . . . . . . . . . .  3
-     2.2.  SHA-256 Support  . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Security Concerns  . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Clarifications on Non-Existence Proofs . . . . . . . . . .  4
-     3.2.  Validating Responses to an ANY Query . . . . . . . . . . .  4
-     3.3.  Check for CNAME  . . . . . . . . . . . . . . . . . . . . .  5
-     3.4.  Insecure Delegation Proofs . . . . . . . . . . . . . . . .  5
-   4.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
-     4.1.  Errors in Canonical Form Type Code List  . . . . . . . . .  5
-     4.2.  Unknown DS Message Digest Algorithms . . . . . . . . . . .  5
-     4.3.  Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
-     4.4.  Caution About Local Policy and Multiple RRSIGs . . . . . .  7
-     4.5.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
-     4.6.  Setting the DO Bit on Replies  . . . . . . . . . . . . . .  7
-     4.7.  Setting the AD bit on Replies  . . . . . . . . . . . . . .  7
-     4.8.  Setting the CD bit on Requests . . . . . . . . . . . . . .  8
-     4.9.  Nested Trust Anchors . . . . . . . . . . . . . . . . . . .  8
-   5.  Minor Corrections and Clarifications . . . . . . . . . . . . .  8
-     5.1.  Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . .  8
-     5.2.  Clarifications on DNSKEY Usage . . . . . . . . . . . . . .  9
-     5.3.  Errors in Examples . . . . . . . . . . . . . . . . . . . .  9
-     5.4.  Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . .  9
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
-   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 11
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
+     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



@@ -106,18 +108,18 @@ Table of Contents



-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 2]
+Weiler & Blacka           Expires May 14, 2011                  [Page 2]

-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes        November 2010


 1.  Introduction and Terminology

   This document lists some additions, clarifications and corrections to
   the core DNSSECbis specification, as originally described in
-   [RFC4033], [RFC4034], and [RFC4035].
+   [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
+   (See section Section 2 for more recent additions to that core
+   document set.)

   It is intended to serve as a resource for implementors and as a
   repository of items that need to be addressed when advancing the
@@ -139,8 +141,9 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009

 2.  Important Additions to DNSSSECbis

-   This section updates the set of core DNSSEC protocol documents
-   originally specified in Section 10 of [RFC4033].
+   This section lists some documents that should be considered core
+   DNSSEC protocol documents in addition to those originally specified
+   in Section 10 of [RFC4033].

 2.1.  NSEC3 Support

@@ -154,32 +157,48 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   [RFC5155] should be considered part of the DNS Security Document
   Family as described by [RFC4033], Section 10.

-2.2.  SHA-256 Support
-
-   [RFC4509] describes the use of SHA-256 as a digest algorithm for use
-   with Delegation Signer (DS) RRs.  [I-D.ietf-dnsext-dnssec-rsasha256]
-   describes the use of the RSASHA256 algorithm for use in DNSKEY and
-   RRSIG RRs.  Validator implementations are strongly encouraged to
-   include support for this algorithm for DS, DNSKEY, and RRSIG records.
+   Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
+   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 March 9, 2010                 [Page 3]
+Weiler & Blacka           Expires May 14, 2011                  [Page 3]

-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes        November 2010


-   Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be
-   considered part of the DNS Security Document Family as described by
-   [RFC4033], Section 10.
+   MUST support both NSEC3 and NSEC responses.
+
+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 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
@@ -198,6 +217,14 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   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
@@ -205,7 +232,7 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
   (original) owner name.

-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
@@ -217,19 +244,11 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   QNAME and QCLASS MUST be validated.  If any of those RRsets fail
   validation, the answer is considered Bogus.  If there are no RRsets
   matching QNAME and QCLASS, that fact MUST be validated according to
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 4]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
   the rules in [RFC4035] Section 5.4 (as clarified in this document).
   To be clear, a validator must not expect to receive all records at
   the QNAME in response to QTYPE=*.

-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/
@@ -238,7 +257,7 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   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
@@ -251,9 +270,18 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   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.
@@ -268,19 +296,11 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   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
   algorithms, as indicated by the key algorithms shown in those zone's
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 5]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
   DS RRsets.  It does not explicitly address how to handle DS records
   that use unsupported message digest algorithms.  In brief, DS records
   using unknown or unsupported message digest algorithms MUST be
@@ -305,10 +325,18 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   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
@@ -319,7 +347,7 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   needed.  In the remaining cases, the security status of the zone
   depends on whether or not the resolver supports any of the private
   algorithms in use (provided that these DS records use supported hash
-   functions, as discussed in Section 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
@@ -329,17 +357,9 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   discussed in [RFC4035].

   This clarification facilitates the broader use of private algorithms,
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 6]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
   as suggested by [RFC4955].

-4.4.  Caution About Local Policy and Multiple RRSIGs
+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
@@ -358,25 +378,38 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   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

-   [RFC4035] does not provide any instructions to servers as to how to
-   set the DO bit.  Some authoritative server implementations have
-   chosen to copy the DO bit settings from the incoming query to the
-   outgoing response.  Others have chosen to never set the DO bit in
-   responses.  Either behavior is permitted.  To be clear, in replies to
-   queries with the DO-bit set servers may or may not set the DO bit.
+   As stated in [RFC3225], the DO bit of the query MUST be copied in the
+   response.  At least one implementation has done something different,
+   so it may be wise for resolvers to be liberal in what they accept.

-4.7.  Setting the AD bit on Replies
+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
+   understands and is interested in the value of the AD bit in the
+   response.  This allows a requestor to indicate that it understands
+   the AD bit without also requesting DNSSEC data via the DO bit.
+
+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
@@ -385,27 +418,38 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   conditions listed in RFC 4035, section 3.2.3, and the request
   contained either a set DO bit or a set AD bit.

+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
+   DNSSEC validation.  RFC4035 section 3.2.2 requires a resolver
+   processing a request with the CD bit set to set the CD bit on its
+   upstream queries.
+
+   The guidance in RFC4035 is ambiguous about what to do when a cached
+   response was obtained with the CD bit not set.  In the typical case,
+   no new query is required, nor does the cache need to track the state
+   of the CD bit used to make a given query.  The problem arises when
+   the cached response is a server failure (RCODE 2), which may indicate
+   that the requested data failed DNSSEC validation at an upstream
+   validating resolver.  (RFC2308 permits caching of server failures for
+   up to five minutes.)  In these cases, a new query with the CD bit set
+   is required.
+
+   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).



-Weiler & Blacka           Expires March 9, 2010                 [Page 7]
+
+
+Weiler & Blacka           Expires May 14, 2011                  [Page 8]

-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes        November 2010


-   Note that the use of the AD bit in the query was previously
-   undefined.  This document defines it as a signal indicating that the
-   requester understands and is interested in the value of the AD bit in
-   the response.  This allows a requestor to indicate that it
-   understands the AD bit without also requesting DNSSEC data via the DO
-   bit.
-
-4.8.  Setting the CD bit on Requests
-
-   When processing a request with the CD bit set, the resolver MUST set
-   the CD bit on its upstream queries.
-
-4.9.  Nested Trust Anchors
+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
@@ -414,18 +458,91 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   When the validator is asked to validate a response to
   "www.sub.zone.example.", either trust anchor could apply.

-   When presented with this situation, DNSSEC validators SHOULD try all
-   applicable trust anchors until one succeeds.
+   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 5.10.2 while exposing other policies as
+   configuration options.

-   There are some scenarios where different behaviors, such as choosing
-   the trust anchor closest to the QNAME of the response, may be
-   desired.  A DNSSEC validator MAY enable such behaviors as
-   configurable overrides.
+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
+   anchor.
+
+   This policy has the advantage of allowing the operator to trivially
+   override a parent zone's trust anchor with one that the operator can
+   validate in a stronger way, perhaps because the resolver operator is
+   affiliated with the zone in question.  This policy also minimizes the
+   number of public key operations needed, which may be of benefit in
+   resource-constrained environments.
+
+   This policy has the disadvantage of possibly giving the user some
+   unexpected and unnecessary validation failures when sub-zone trust
+   anchors are neglected.  As a concrete example, consider a validator
+   that configured a trust anchor for "zone.example." in 2009 and one
+   for "example." in 2011.  In 2012, "zone.example." rolls its KSK and
+   updates its DS records, but the validator operator doesn't update its
+   trust anchor.  With the "closest encloser" policy, the validator gets
+   validation failures.
+
+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
+   result is Secure.  If and only if all applicable trust anchors give a
+   result of Insecure, the final validation result is Insecure.  If one
+   or more trust anchors lead to a Bogus result and there is no Secure
+   result, then the final validation result is Bogus.


-5.  Minor Corrections and Clarifications

-5.1.  Finding Zone Cuts
+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
+   get a Secure validation result (and see DNS responses).
+
+   This policy has the disadvantage of making the validator subject to
+   compromise of the weakest of these trust anchors while making its
+   relatively painless to keep old trust anchors configured in
+   perpetuity.
+
+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
+   ([RFC5074]), and manually configured), a validator may wish to choose
+   between them based on the perceived reliability of those sources.
+   The order of precedence might be exposed as a configuration option.
+
+   For example, a validator might choose to prefer trust anchors found
+   in a DLV registry over those manually configured on the theory that
+   the manually configured ones will not be as aggressively maintained.
+
+   Conversely, a validator might choose to prefer manually configured
+   trust anchors over those obtained from a DLV registry on the theory
+   that the manually configured ones have been more carefully
+   authenticated.
+
+   Or the validator might do something more complicated: prefer a sub-
+   set of manually configured trust anchors (based on a configuration
+   option), then trust anchors that have been updated using the RFC5011
+   mechanism, then trust anchors from one DLV registry, then trust
+   anchors from a different DLV registry, then the rest of the manually
+   configured trust anchors.
+
+
+6.  Minor Corrections and Clarifications
+
+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
@@ -436,20 +553,17 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   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.

-
-
-
-
-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 8]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
-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.
@@ -473,7 +587,7 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   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
@@ -488,23 +602,25 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   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:

-
-
-Weiler & Blacka           Expires March 9, 2010                 [Page 9]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+

   The plus sign in the regular expression indicates that there is one
@@ -516,51 +632,49 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
      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
-
-   [I-D.ietf-dnsext-dnssec-rsasha256]
-              Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
-              and RRSIG Resource Records for DNSSEC",
-              draft-ietf-dnsext-dnssec-rsasha256-14 (work in progress),
-              June 2009.
+9.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              RFC 1034, STD 13, November 1987.
+              STD 13, RFC 1034, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, BCP 14, March 1997.
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
+              RFC 3225, December 2001.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.



-Weiler & Blacka           Expires March 9, 2010                [Page 10]
+Weiler & Blacka           Expires May 14, 2011                 [Page 12]

-Internet-Draft       DNSSECbis Implementation Notes       September 2009
+Internet-Draft       DNSSECbis Implementation Notes        November 2010


+              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.
@@ -576,7 +690,11 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, March 2008.

-8.2.  Informative References
+   [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
+              and RRSIG Resource Records for DNSSEC", RFC 5702,
+              October 2009.
+
+9.2.  Informative References

   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
              Signer (DS)", RFC 3755, May 2004.
@@ -587,6 +705,12 @@ Internet-Draft       DNSSECbis Implementation Notes       September 2009
   [RFC4955]  Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
              July 2007.

+   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+              Trust Anchors", RFC 5011, September 2007.
+
+   [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+              November 2007.
+

 Appendix A.  Acknowledgments

@@ -597,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.
+   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 3.1 was found by
+   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.

-
-
-
-Weiler & Blacka           Expires March 9, 2010                [Page 11]
-
-Internet-Draft       DNSSECbis Implementation Notes       September 2009
-
-
   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 Ed Lewis, Danny Mayer, Olafur
-   Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive
-   comments on the text of this document.
+   The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
+   Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
+   and Scott Rose for their substantive comments on the text of this
+   document.


 Authors' Addresses
@@ -655,18 +780,6 @@ Authors' Addresses



-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka           Expires March 9, 2010                [Page 12]
+Weiler & Blacka           Expires May 14, 2011                 [Page 14]

+
@@ -1,444 +0,0 @@
-DNS Extensions working group                             V.Dolmatov, Ed.  
-Internet-Draft                                            Cryptocom Ltd.    
-Intended status: Standards Track                      December 12, 2009
-Expires: June 12, 2010                                 
-
-
- Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
-                               for DNSSEC
-                 draft-ietf-dnsext-dnssec-gost-06
-
-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 June 12 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   This document describes how to produce signature and hash using 
-   GOST algorithms [DRAFT1, DRAFT2, DRAFT3] for DNSKEY, RRSIG and DS
-   resource records for use in the Domain Name System Security 
-   Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
-
-V.Dolmatov              Expires June 12, 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, GOST R 34.11-94, GOST 28147-89. 
-   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 June 12, 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} (GOST)
-   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c
-             t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA=
- 
-
-V.Dolmatov              Expires June 12, 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 June 12, 2010                [Page 4]
-
-  Note: Several GOST signatures calculated for the same message text 
-   differ because of using of a random element is used in signature 
-   generation process.
-
-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 SHOULD be able to support RRSIG and
-   DNSKEY resource records created with the GOST algorithms as
-   defined in this document.
-
-V.Dolmatov              Expires June 12, 2010                [Page 5]
-
-6.2.  Support for NSEC3 Denial of Existence
-
-    Any DNSSEC-GOST implementation is required to have either NSEC or
-    NSEC3 support.
-
-6.3  Byte order
-
-    Due to the fact that all existing industry implementations of GOST
-    cryptographic libraries are returning GOST blobs in little-endian 
-    format and in order to avoid the necessity for DNSSEC developers 
-    to handle different cryptographic algorithms differently, it was
-    chosen to send these blobs on the wire "as is" without 
-    transformation of endianness.
-
-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 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 June 12, 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 June 12, 2010               [Page 7]
-
-
-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-07, 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-06, 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-06, 12.12.09
-              work in progress.
-
-V.Dolmatov              Expires June 12, 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 June 12, 2010                [Page 9]
-
-
-
-
-
@@ -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]
+
@@ -5,13 +5,13 @@ DNS Extensions Working Group                                     S. Rose
 Internet-Draft                                                      NIST
 Obsoletes: 2672 (if approved)                              W. Wijngaards
 Updates: 3363,4294                                            NLnet Labs
-(if approved)                                          November 12, 2009
+(if approved)                                             April 20, 2010
 Intended status: Standards Track
-Expires: May 16, 2010
+Expires: October 22, 2010


                 Update to DNAME Redirection in the DNS
-                 draft-ietf-dnsext-rfc2672bis-dname-18
+                 draft-ietf-dnsext-rfc2672bis-dname-19

 Abstract

@@ -48,18 +48,18 @@ Status of This Memo
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

-   This Internet-Draft will expire on May 16, 2010.
+   This Internet-Draft will expire on October 22, 2010.



-Rose & Wijngaards         Expires May 16, 2010                  [Page 1]
+Rose & Wijngaards       Expires October 22, 2010                [Page 1]

-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010


 Copyright Notice

-   Copyright (c) 2009 IETF Trust and the persons identified as the
+   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
@@ -108,9 +108,9 @@ Copyright Notice



-Rose & Wijngaards         Expires May 16, 2010                  [Page 2]
+Rose & Wijngaards       Expires October 22, 2010                [Page 2]

-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010


 Table of Contents
@@ -120,40 +120,40 @@ Table of Contents
   2.  The DNAME Resource Record  . . . . . . . . . . . . . . . . . .  4
     2.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  The DNAME Substitution . . . . . . . . . . . . . . . . . .  5
-     2.3.  DNAME Owner Name not Redirected Itself . . . . . . . . . .  6
+     2.3.  DNAME Owner Name Matching the QNAME  . . . . . . . . . . .  7
     2.4.  Names Next to and Below a DNAME Record . . . . . . . . . .  7
     2.5.  Compression of the DNAME record. . . . . . . . . . . . . .  7

   3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  CNAME synthesis  . . . . . . . . . . . . . . . . . . . . .  8
-     3.2.  Server algorithm . . . . . . . . . . . . . . . . . . . . .  8
-     3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 10
-     3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 10
+     3.2.  Server algorithm . . . . . . . . . . . . . . . . . . . . .  9
+     3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 11
+     3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 11

   4.  DNAME Discussions in Other Documents . . . . . . . . . . . . . 11

-   5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 12
-     5.1.  Canonical hostnames cannot be below DNAME owners . . . . . 12
-     5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 12
+   5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 13
+     5.1.  Canonical hostnames cannot be below DNAME owners . . . . . 13
+     5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13
     5.3.  DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13
       5.3.1.  Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13
-       5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 13
-       5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 13
-       5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 13
-         5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error  . . . . 13
+       5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
+       5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 14
+       5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 14
+         5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error  . . . . 14
         5.3.4.2.  Valid Name Error Response Involving DNAME in
-                   Bitmap . . . . . . . . . . . . . . . . . . . . . . 14
-         5.3.4.3.  Response With Synthesized CNAME  . . . . . . . . . 14
+                   Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
+         5.3.4.3.  Response With Synthesized CNAME  . . . . . . . . . 15

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15

-   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
+   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16

-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17



@@ -164,9 +164,9 @@ Table of Contents



-Rose & Wijngaards         Expires May 16, 2010                  [Page 3]
+Rose & Wijngaards       Expires October 22, 2010                [Page 3]

-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010


 1.  Introduction
@@ -180,7 +180,7 @@ Internet-Draft              DNAME Redirection              November 2009
   from the queried domain name.  The difference between the two
   resource records is that the CNAME RR directs the lookup of data at
   its owner to another single name, a DNAME RR directs lookups for data
-   at descendents of its owner's name to corresponding names under a
+   at descendants of its owner's name to corresponding names under a
   different (single) node of the tree.

   Take for example, looking through a zone (see RFC 1034 [RFC1034],
@@ -220,9 +220,9 @@ Internet-Draft              DNAME Redirection              November 2009



-Rose & Wijngaards         Expires May 16, 2010                  [Page 4]
+Rose & Wijngaards       Expires October 22, 2010                [Page 4]

-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010


   Its RDATA is comprised of a single field, <target>, which contains a
@@ -234,9 +234,10 @@ Internet-Draft              DNAME Redirection              November 2009

   The effect of the DNAME RR is the substitution of the record's
   <target> for its owner name, as a suffix of a domain name.  This
-   substitution has to be applied for every DNAME RR found in the
-   resolution process, which allows fairly lengthy valid chains of DNAME
-   RRs.
+   substitution is to be applied for all names below the owner name of
+   the DNAME RR.  This substitution has to be applied for every DNAME RR
+   found in the resolution process, which allows fairly lengthy valid
+   chains of DNAME RRs.

   Details of the substitution process, methods to avoid conflicting
   resource records, and rules for specific corner cases are given in
@@ -275,10 +276,9 @@ Internet-Draft              DNAME Redirection              November 2009



-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 5]
+Rose & Wijngaards       Expires October 22, 2010                [Page 5]

-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010


   In the table below, the QNAME refers to the query name.  The owner is
@@ -293,7 +293,7 @@ Internet-Draft              DNAME Redirection              November 2009
    QNAME            owner  DNAME   target         result
    ---------------- -------------- -------------- -----------------
    com.             example.com.   example.net.   <no match>
-    example.com.     example.com.   example.net.   <no match>
+    example.com.     example.com.   example.net.   [0]
    a.example.com.   example.com.   example.net.   a.example.net.
    a.b.example.com. example.com.   example.net.   a.b.example.net.
    ab.example.com.  b.example.com. example.net.   <no match>
@@ -305,6 +305,9 @@ Internet-Draft              DNAME Redirection              November 2009
    shortloop.x.x.   x.             .              shortloop.x.
    shortloop.x.     x.             .              shortloop.

+   [0] The result depends on the QTYPE.  If the QTYPE = DNAME, then
+       the result is "example.com." else "<no match>"
+
                   Table 1. DNAME Substitution Examples.

   It is possible for DNAMEs to form loops, just as CNAMEs can form
@@ -323,23 +326,32 @@ Internet-Draft              DNAME Redirection              November 2009
   DNAME record and its signature (if the zone is signed) are included
   in the answer as proof for the YXDOMAIN (value 6) RCODE.

-2.3.  DNAME Owner Name not Redirected Itself
+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 6]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
+2.3.  DNAME Owner Name Matching the QNAME

   Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
   owner name; the owner name of a DNAME is not redirected itself.  The
   domain name that owns a DNAME record is allowed to have other
   resource record types at that domain name, except DNAMEs, CNAMEs or
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 6]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
   other types that have restrictions on what they can co-exist with.
+   When there is a match of the QTYPE to a type (or types) also owned by
+   the owner name the response is sourced from the owner name.  E.g., a
+   QTYPE of ANY would return the (available) types at the owner name,
+   not the target name.
+
   DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
-   the owner name is the zone apex.
+   the owner name is the zone apex as this would constitute data below a
+   zone cut.

   If a DNAME record is present at the zone apex, there is still a need
   to have the customary SOA and NS resource records there as well.
@@ -373,6 +385,14 @@ Internet-Draft              DNAME Redirection              November 2009

   The DNAME owner name can be compressed like any other owner name.
   The DNAME RDATA target name MUST NOT be sent out in compressed form,
+
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 7]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
   so that a DNAME RR can be treated as an unknown type [RFC3597].

   Although the previous DNAME specification [RFC2672] (that is
@@ -386,13 +406,6 @@ Internet-Draft              DNAME Redirection              November 2009
   compression.  This document revises RFC 2672, in that there is no
   EDNS version signaling for DNAME.

-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 7]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
 3.  Processing

   The DNAME RR causes type NS additional section processing.  This
@@ -403,22 +416,44 @@ Internet-Draft              DNAME Redirection              November 2009

   When preparing a response, a server performing a DNAME substitution
   will in all cases include the relevant DNAME RR in the answer
-   section.  A CNAME RR with TTL equal to the corresponding DNAME RR is
-   synthesized and included in the answer section.  The owner name of
-   the CNAME is the QNAME of the query.  The DNSSEC specification
-   [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does
-   not have to be signed.  The DNAME has an RRSIG and a validating
-   resolver can check the CNAME against the DNAME record and validate
-   the signature over the DNAME RR.
+   section.  Relevant includes the following cases:

-   Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
-   equal to the TTL of the corresponding DNAME record.  A TTL of zero
-   means that the CNAME can be discarded immediately after processing
-   the answer.
+   1.  The DNAME is being employed as a substitution instruction.
+
+   2.  The DNAME itself matches the QTYPE and the owner name matches
+       QNAME.
+
+   When the owner name name matches the QNAME and the QTYPE matches
+   another type owned there, the DNAME is not included in the answer.
+
+   A CNAME RR with TTL equal to the corresponding DNAME RR is
+   synthesized and included in the answer section when the DNAME is
+   employed as a substitution instruction.  The owner name of the CNAME
+   is the QNAME of the query.  The DNSSEC specification [RFC4033],
+   [RFC4034], [RFC4035] says that the synthesized CNAME does not have to
+   be signed.  The DNAME has an RRSIG and a validating resolver can
+   check the CNAME against the DNAME record and validate the signature
+   over the DNAME RR.

   Servers MUST be able to answer a query for a synthesized CNAME.  Like
   other query types this invokes the DNAME, and synthesizes the CNAME
-   into the answer.
+   into the answer.  If the server in question is a cache, the
+   synthesized CNAME's TTL SHOULD be equal to the decremented TTL of the
+   cached DNAME.
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 8]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
+   Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
+   equal to the TTL of the corresponding DNAME record (as some older
+   authoritative server implementations set the TTL of synthesized
+   CNAMEs to zero).  A TTL of zero means that the CNAME can be discarded
+   immediately after processing the answer.

 3.2.  Server algorithm

@@ -441,14 +476,6 @@ Internet-Draft              DNAME Redirection              November 2009
       process can terminate several ways:


-
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 8]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
       A.  If the whole of QNAME is matched, we have found the node.

           If the data at the node is a CNAME, and QTYPE does not match
@@ -471,6 +498,13 @@ Internet-Draft              DNAME Redirection              November 2009
           4.


+
+
+Rose & Wijngaards       Expires October 22, 2010                [Page 9]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
       C.  If at some label, a match is impossible (i.e., the
           corresponding label does not exist), look to see whether the
           last label matched has a DNAME record.
@@ -497,14 +531,6 @@ Internet-Draft              DNAME Redirection              November 2009
           set the owner of the RR to be QNAME, and not the node with
           the "*" label.  If the data at the node with the "*" label is
           a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                  [Page 9]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
           into the answer section of the response changing the owner
           name to the QNAME, change QNAME to the canonical name in the
           CNAME RR, and go back to step 1.  Otherwise, Go to step 6.
@@ -527,6 +553,14 @@ Internet-Draft              DNAME Redirection              November 2009
   6.  Using local data only, attempt to add other RRs which may be
       useful to the additional section of the query.  Exit.

+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 10]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
   Note that there will be at most one ancestor with a DNAME as
   described in step 4 unless some zone's data is in violation of the
   no-descendants limitation in section 3.  An implementation might take
@@ -553,14 +587,6 @@ Internet-Draft              DNAME Redirection              November 2009
   Recursive caching name servers can encounter data at names below the
   owner name of a DNAME RR, due to a change at the authoritative server
   where data from before and after the change resides in the cache.
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 10]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
   This conflict situation is a transitional phase that ends when the
   old data times out.  The caching name server can opt to store both
   old and new data and treat each as if the other did not exist, or
@@ -580,6 +606,17 @@ Internet-Draft              DNAME Redirection              November 2009
   In [RFC2181], in Section 10.3., the discussion on MX and NS records
   touches on redirection by CNAMEs, but this also holds for DNAMEs.

+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 11]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
   Excerpt from 10.3.  MX and NS records (in RFC 2181).

           The domain name used as the value of a NS resource record,
@@ -604,19 +641,6 @@ Internet-Draft              DNAME Redirection              November 2009
   would greatly improve the manageability of the IPv6 reverse tree.
   These changes are made explicit below.

-
-
-
-
-
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 11]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
   In [RFC3363], the paragraph

     "The issues for DNAME in the reverse mapping tree appears to be
@@ -639,6 +663,16 @@ Internet-Draft              DNAME Redirection              November 2009
     "Those nodes are NOT RECOMMENDED to support the experimental
     A6 Resource Record [RFC3363]."

+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 12]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
 5.  Other Issues with DNAME

   There are several issues to be aware of about the use of DNAME.
@@ -665,19 +699,13 @@ Internet-Draft              DNAME Redirection              November 2009

   DNAME records can be added, changed and removed in a zone using
   dynamic update transactions.  Adding a DNAME RR to a zone occludes
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 12]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
   any domain names that may exist under the added DNAME.

-   A server MUST reject a dynamic update message that attempts to add a
-   DNAME RR at a name that already has a CNAME RR or another DNAME RR
-   associated with that name.
+   A server MUST ignore a dynamic update message that attempts to add a
+   non-DNAME/CNAME RR at a name that already has a DNAME RR associated
+   with that name.  Otherwise, replace the DNAME RR with the DNAME (or
+   CNAME) update RR.  This is similar behavior to dynamic updates to an
+   owner name of a CNAME RR [RFC2136].

 5.3.  DNSSEC and DNAME

@@ -693,12 +721,20 @@ Internet-Draft              DNAME Redirection              November 2009
   RR and then checking that the CNAME was properly synthesized is
   sufficient proof.

+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 13]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
 5.3.2.  DNAME Bit in NSEC Type Map

   In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
   map SHOULD be checked to see that there was no DNAME that could have
   been applied.  If the DNAME bit in the type bit map is set and the
-   query name is a subdomain of the closest encloser that is asserted,
+   query name is a sub-domain of the closest encloser that is asserted,
   then DNAME substitution should have been done, but the substitution
   has not been done as specified.

@@ -715,21 +751,14 @@ Internet-Draft              DNAME Redirection              November 2009

   Below are examples of why DNSSEC validators MUST understand DNAME.
   In the examples below, SOA records, wildcard denial NSECs and other
-   material not under discussion has been omitted.
+   material not under discussion has been omitted or shortened.

 5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error

+   ;; Header: QR AA RCODE=3(NXDOMAIN)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096

-
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 13]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
-   ;; Header: QR AA DO RCODE=3(NXDOMAIN)
   ;; Question
   foo.bar.example.com. IN A
   ;; Authority
@@ -745,9 +774,23 @@ Internet-Draft              DNAME Redirection              November 2009
   If the DNAME bit had not been set in the NSEC record above then the
   answer would have validated as a correct name error response.

+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 14]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
 5.3.4.2.  Valid Name Error Response Involving DNAME in Bitmap

-   ;; Header: QR AA DO RCODE=3(NXDOMAIN)
+   ;; Header: QR AA RCODE=3(NXDOMAIN)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
+
   ;; Question
   cee.example.com. IN A
   ;; Authority
@@ -760,7 +803,10 @@ Internet-Draft              DNAME Redirection              November 2009

 5.3.4.3.  Response With Synthesized CNAME

-   ;; Header: QR AA DO RCODE=0(NOERROR)
+   ;; Header: QR AA RCODE=0(NOERROR)
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags: do; udp: 4096
+
   ;; Question
   foo.bar.example.com. IN A
   ;; Answer
@@ -777,14 +823,6 @@ Internet-Draft              DNAME Redirection              November 2009
   recursively resolve further to query for the foo.bar.example.net A
   record.

-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 14]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
 6.  IANA Considerations

   The DNAME Resource Record type code 39 (decimal) originally has been
@@ -795,6 +833,14 @@ Internet-Draft              DNAME Redirection              November 2009

   DNAME redirects queries elsewhere, which may impact security based on
   policy and the security status of the zone with the DNAME and the
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 15]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
   redirection zone's security status.  For validating resolvers, the
   lowest security status of the links in the chain of CNAME and DNAME
   redirections is applied to the result.
@@ -833,14 +879,6 @@ Internet-Draft              DNAME Redirection              November 2009

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-
-
-
-Rose & Wijngaards         Expires May 16, 2010                 [Page 15]
-
-Internet-Draft              DNAME Redirection              November 2009
-
-
              RFC 2136, April 1997.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
@@ -851,6 +889,14 @@ Internet-Draft              DNAME Redirection              November 2009
              February 2000.

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 16]
+
+Internet-Draft              DNAME Redirection                 April 2010
+
+
              (RR) Types", RFC 3597, September 2003.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
@@ -892,9 +938,19 @@ Internet-Draft              DNAME Redirection              November 2009



-Rose & Wijngaards         Expires May 16, 2010                 [Page 16]
+
+
+
+
+
+
+
+
+
+
+Rose & Wijngaards       Expires October 22, 2010               [Page 17]

-Internet-Draft              DNAME Redirection              November 2009
+Internet-Draft              DNAME Redirection                 April 2010


 Authors' Addresses
@@ -907,7 +963,7 @@ Authors' Addresses

   Phone: +1-301-975-8439
   Fax:   +1-301-975-6238
-   EMail: scottr@nist.gov
+   EMail: scottr.nist@gmail.com


   Wouter Wijngaards
@@ -948,6 +1004,5 @@ Authors' Addresses



-Rose & Wijngaards         Expires May 16, 2010                 [Page 17]
+Rose & Wijngaards       Expires October 22, 2010               [Page 18]

-
@@ -3,12 +3,12 @@

 Network Working Group                                         M. Andrews
 Internet-Draft                                                       ISC
-Intended status: BCP                                   November 19, 2009
-Expires: May 23, 2010
+Intended status: BCP                                      March 25, 2010
+Expires: September 26, 2010


                        Locally-served DNS Zones
-                draft-ietf-dnsop-default-local-zones-09
+                draft-ietf-dnsop-default-local-zones-10

 Abstract

@@ -41,20 +41,20 @@ Status of this Memo
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

-   This Internet-Draft will expire on May 23, 2010.
+   This Internet-Draft will expire on September 26, 2010.

 Copyright Notice

-   Copyright (c) 2009 IETF Trust and the persons identified as the
+   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



-Andrews                   Expires May 23, 2010                  [Page 1]
+Andrews                Expires September 26, 2010               [Page 1]

-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010


   Provisions Relating to IETF Documents
@@ -108,9 +108,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009



-Andrews                   Expires May 23, 2010                  [Page 2]
+Andrews                Expires September 26, 2010               [Page 2]

-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010


 Table of Contents
@@ -121,9 +121,9 @@ Table of Contents
   3.  Changes to Iterative Resolver Behaviour. . . . . . . . . . . .  4
   4.  Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . .  5
     4.1.  RFC1918 Zones  . . . . . . . . . . . . . . . . . . . . . .  5
-     4.2.  RFC3330 Zones  . . . . . . . . . . . . . . . . . . . . . .  6
+     4.2.  RFC3330 and RFC5737 Zones  . . . . . . . . . . . . . . . .  6
     4.3.  Local IPv6 Unicast Addresses . . . . . . . . . . . . . . .  6
-     4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  6
+     4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  7
     4.5.  IPv6 Link Local Addresses  . . . . . . . . . . . . . . . .  7
     4.6.  IPv6 Example Prefix  . . . . . . . . . . . . . . . . . . .  7
   5.  Zones that are Out-Of-Scope  . . . . . . . . . . . . . . . . .  7
@@ -134,18 +134,19 @@ Table of Contents
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Change History [To Be Removed on Publication] . . . . 10
-     A.1.  draft-ietf-dnsop-default-local-zones-09.txt  . . . . . . . 10
-     A.2.  draft-ietf-dnsop-default-local-zones-08.txt  . . . . . . . 10
-     A.3.  draft-ietf-dnsop-default-local-zones-07.txt  . . . . . . . 10
-     A.4.  draft-ietf-dnsop-default-local-zones-06.txt  . . . . . . . 10
-     A.5.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 11
-     A.6.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 11
-     A.7.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 11
-     A.8.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 11
-     A.9.  draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
-     A.10. draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
-     A.11. draft-andrews-full-service-resolvers-03.txt  . . . . . . . 11
-     A.12. draft-andrews-full-service-resolvers-02.txt  . . . . . . . 12
+     A.1.  draft-ietf-dnsop-default-local-zones-10.txt  . . . . . . . 10
+     A.2.  draft-ietf-dnsop-default-local-zones-09.txt  . . . . . . . 10
+     A.3.  draft-ietf-dnsop-default-local-zones-08.txt  . . . . . . . 11
+     A.4.  draft-ietf-dnsop-default-local-zones-07.txt  . . . . . . . 11
+     A.5.  draft-ietf-dnsop-default-local-zones-06.txt  . . . . . . . 11
+     A.6.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 11
+     A.7.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 11
+     A.8.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 11
+     A.9.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 11
+     A.10. draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
+     A.11. draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
+     A.12. draft-andrews-full-service-resolvers-03.txt  . . . . . . . 12
+     A.13. draft-andrews-full-service-resolvers-02.txt  . . . . . . . 12
   Appendix B.  Proposed Status [To Be Removed on Publication]  . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12

@@ -163,10 +164,9 @@ Table of Contents



-
-Andrews                   Expires May 23, 2010                  [Page 3]
+Andrews                Expires September 26, 2010               [Page 3]

-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010


 1.  Introduction
@@ -220,9 +220,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009



-Andrews                   Expires May 23, 2010                  [Page 4]
+Andrews                Expires September 26, 2010               [Page 4]

-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010


 2.  Effects on sites using RFC 1918 addresses.
@@ -276,9 +276,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009



-Andrews                   Expires May 23, 2010                  [Page 5]
+Andrews                Expires September 26, 2010               [Page 5]

-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010


   The SOA RR is needed to support negative caching [RFC2308] of name
@@ -332,16 +332,17 @@ Internet-Draft          Locally-served DNS Zones           November 2009



-Andrews                   Expires May 23, 2010                  [Page 6]
+Andrews                Expires September 26, 2010               [Page 6]

-Internet-Draft          Locally-served DNS Zones           November 2009
+Internet-Draft          Locally-served DNS Zones              March 2010


-4.2.  RFC3330 Zones
+4.2.  RFC3330 and RFC5737 Zones

   The following zones correspond to those address ranges from [RFC3330]
-   that are not expected to appear as source or destination addresses on
-   the public Internet and to not have a unique name to associate with.
+   and [RFC5737] that are not expected to appear as source or
+   destination addresses on the public Internet and to not have a unique
+   name to associate with.

   The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
   attempt to discourage any practice to provide a PTR RR for
@@ -357,7 +358,9 @@ Internet-Draft          Locally-served DNS Zones           November 2009
         | 0.IN-ADDR.ARPA               | IPv4 "THIS" NETWORK    |
         | 127.IN-ADDR.ARPA             | IPv4 LOOP-BACK NETWORK |
         | 254.169.IN-ADDR.ARPA         | IPv4 LINK LOCAL        |
-         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST NET          |
+         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST NET 1        |
+         | 100.51.198.IN-ADDR.ARPA      | IPv4 TEST NET 2        |
+         | 113.0.203.IN-ADDR.ARPA       | IPv4 TEST NET 3        |
         | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST         |
         +------------------------------+------------------------+

@@ -380,19 +383,20 @@ Internet-Draft          Locally-served DNS Zones           November 2009
   readability and to adhere to line width constraints.  They are not
   parts of the zone names.

+
+
+
+
+
+Andrews                Expires September 26, 2010               [Page 7]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
 4.4.  IPv6 Locally Assigned Local Addresses

   Section 4.4 of [RFC4193] already required special treatment of:

-
-
-
-
-Andrews                   Expires May 23, 2010                  [Page 7]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
                             +--------------+
                             | Zone         |
                             +--------------+
@@ -438,17 +442,16 @@ Internet-Draft          Locally-served DNS Zones           November 2009
   F.E.F.IP6.ARPA may still need to be deployed in the short term if the
   traffic becomes excessive.

+
+
+Andrews                Expires September 26, 2010               [Page 8]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
   For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC4193],
   there has been no decision made about whether the Regional Internet
   Registries (RIRs) will provide delegations in this space or not.  If
-
-
-
-Andrews                   Expires May 23, 2010                  [Page 8]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
   they don't, then C.F.IP6.ARPA will need to be added to the list in
   Section 4.4.  If they do, then registries will need to take steps to
   ensure that name servers are provided for these addresses.
@@ -494,17 +497,17 @@ Internet-Draft          Locally-served DNS Zones           November 2009
   DNSSEC validation to succeed for queries in these spaces despite not
   being answered from the delegated servers.

+
+
+
+Andrews                Expires September 26, 2010               [Page 9]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
   It is recommended that sites actively using these namespaces secure
   them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
   anchors.  This will protect the clients from accidental import of
-
-
-
-Andrews                   Expires May 23, 2010                  [Page 9]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
   unsigned responses from the Internet.


@@ -551,16 +554,16 @@ Internet-Draft          Locally-served DNS Zones           November 2009
   [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
              August 2005.

+
+
+Andrews                Expires September 26, 2010              [Page 10]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

-
-
-Andrews                   Expires May 23, 2010                 [Page 10]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

@@ -588,45 +591,54 @@ Internet-Draft          Locally-served DNS Zones           November 2009
   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
              Reserved for Documentation", RFC 3849, July 2004.

+   [RFC5737]  Arkko, J., Cotton, M., and L. Vergoda, "IPv4 Address
+              Blocks Reserved for Documentation", RFC 5737,
+              January 2010.
+

 Appendix A.  Change History [To Be Removed on Publication]

-A.1.  draft-ietf-dnsop-default-local-zones-09.txt
+A.1.  draft-ietf-dnsop-default-local-zones-10.txt
+
+   added RFC 5737 zones
+
+A.2.  draft-ietf-dnsop-default-local-zones-09.txt

   refresh awaiting writeup

-A.2.  draft-ietf-dnsop-default-local-zones-08.txt
+
+
+
+
+
+
+Andrews                Expires September 26, 2010              [Page 11]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
+A.3.  draft-ietf-dnsop-default-local-zones-08.txt

   editorial, reference updates

-A.3.  draft-ietf-dnsop-default-local-zones-07.txt
+A.4.  draft-ietf-dnsop-default-local-zones-07.txt

   none, expiry prevention

-A.4.  draft-ietf-dnsop-default-local-zones-06.txt
+A.5.  draft-ietf-dnsop-default-local-zones-06.txt

   add IPv6 example prefix

-
-
-
-
-
-Andrews                   Expires May 23, 2010                 [Page 11]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
-A.5.  draft-ietf-dnsop-default-local-zones-05.txt
+A.6.  draft-ietf-dnsop-default-local-zones-05.txt

   none, expiry prevention

-A.6.  draft-ietf-dnsop-default-local-zones-04.txt
+A.7.  draft-ietf-dnsop-default-local-zones-04.txt

   Centrally Assigned Local addresses -> Non-Locally Assigned Local
   address

-A.7.  draft-ietf-dnsop-default-local-zones-03.txt
+A.8.  draft-ietf-dnsop-default-local-zones-03.txt

   expanded section 4 descriptions

@@ -636,44 +648,40 @@ A.7.  draft-ietf-dnsop-default-local-zones-03.txt

   Revised language.

-A.8.  draft-ietf-dnsop-default-local-zones-02.txt
+A.9.  draft-ietf-dnsop-default-local-zones-02.txt

   RNAME now "nobody.invalid."

   Revised language.

-A.9.  draft-ietf-dnsop-default-local-zones-01.txt
+A.10.  draft-ietf-dnsop-default-local-zones-01.txt

   Revised impact description.

   Updated to reflect change in IP6.INT status.

-A.10.  draft-ietf-dnsop-default-local-zones-00.txt
+A.11.  draft-ietf-dnsop-default-local-zones-00.txt

   Adopted by DNSOP.

   "Author's Note" re-titled "Zones that are Out-Of-Scope"

+
+
+Andrews                Expires September 26, 2010              [Page 12]
+
+Internet-Draft          Locally-served DNS Zones              March 2010
+
+
   Add note that these zone are expected to seed the IANA registry.

   Title changed.

-A.11.  draft-andrews-full-service-resolvers-03.txt
+A.12.  draft-andrews-full-service-resolvers-03.txt

   Added "Proposed Status".

-
-
-
-
-
-
-Andrews                   Expires May 23, 2010                 [Page 12]
-
-Internet-Draft          Locally-served DNS Zones           November 2009
-
-
-A.12.  draft-andrews-full-service-resolvers-02.txt
+A.13.  draft-andrews-full-service-resolvers-02.txt

   Added 0.IN-ADDR.ARPA.

@@ -692,7 +700,7 @@ Author's Address
   Redwood City, CA  94063
   US

-   Email: Mark_Andrews@isc.org
+   Email: marka@isc.org



@@ -716,14 +724,5 @@ Author's Address



-
-
-
-
-
-
-
-
-Andrews                   Expires May 23, 2010                 [Page 13]
+Andrews                Expires September 26, 2010              [Page 13]

-
@@ -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]
+
@@ -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]
+
+
+
@@ -1,6 +1,6 @@
-# $Id: SRCID,v 1.17.4.42 2010/03/03 22:17:15 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/03/03 22:17:15 $ )"
+SRCID="( $Date: 2010/11/29 02:15:06 $ )"
@@ -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
+
@@ -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]
+
@@ -1,3 +1,3 @@
-LIBINTERFACE = 38
-LIBREVISION = 0
-LIBAGE = 0
+LIBINTERFACE = 39
+LIBREVISION = 1
+LIBAGE = 1
@@ -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.
@@ -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 */
@@ -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)


 /*%
@@ -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 2010/06/03 23:46:10 tbox Exp $ */

 /*! \file */

@@ -30,6 +30,9 @@
 #include <dns/rdata.h>
 #include <dns/rdatalist.h>
 #include <dns/rdataset.h>
+#include <dns/rdatastruct.h>
+
+#define DNS_NCACHE_RDATA 20U

 /*
 * The format of an ncache rdata is a sequence of one or more records of
@@ -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;
@@ -164,6 +179,8 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 						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;
+}
@@ -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 {
@@ -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);

@@ -15,7 +15,7 @@
 * PERFORMANCE OF THIS SOFTWARE.
 */

-/* $Id: validator.c,v 1.119.18.53 2010/02/26 23:46:37 tbox Exp $ */
+/* $Id: validator.c,v 1.119.18.60 2010/11/16 04:17:44 marka 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);
@@ -335,6 +341,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 {
@@ -475,7 +492,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 +542,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);
@@ -551,6 +569,17 @@ keyvalidated(isc_task_t *task, isc_event_t *event) {
 		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 +630,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 %d",
+			      val->frdataset.type == dns_rdatatype_ds ?
+			      "dsset" : "ds non-existance",
+			      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 +889,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)
@@ -1227,11 +1275,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,
@@ -1453,9 +1504,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 +1519,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 +1580,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 +1777,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 +1823,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 +1841,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 +1861,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 +1908,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 +1927,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 +1952,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,7 +2016,7 @@ validatezonekey(dns_validator_t *val) {
 				      "must be secure failure");
 			return (DNS_R_MUSTBESECURE);
 		}
-		markanswer(val);
+		markanswer(val, "validatezonekey (2)");
 		return (ISC_R_SUCCESS);
 	}

@@ -2074,7 +2162,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 +2188,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 +2272,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 +2409,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,27 +2550,24 @@ 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);
 	}

-	if (val->authcount == val->authfail)
+	if (val->authfail != 0 && val->authcount == val->authfail)
 		return (DNS_R_BROKENCHAIN);
 	validator_log(val, ISC_LOG_DEBUG(3),
 		      "nonexistence proof(s) not found");
@@ -2386,7 +2631,7 @@ dlvvalidated(isc_task_t *task, isc_event_t *event) {
 		if (dlv_algorithm_supported(val))
 			dlv_validator_start(val);
 		else {
-			markanswer(val);
+			markanswer(val, "dlvvalidated");
 			validator_done(val, ISC_R_SUCCESS);
 		}
 	} else {
@@ -2455,7 +2700,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 +2719,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 +2774,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 +2791,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 +2976,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 +3014,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 +3044,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 +3081,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 +3106,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 +3121,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 +3145,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 +3182,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 +3278,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 +3305,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.
@@ -1,3 +1,3 @@
 LIBINTERFACE = 37
-LIBREVISION = 0
+LIBREVISION = 1
 LIBAGE = 1
@@ -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--;
 				}
@@ -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;
+}
@@ -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
@@ -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";
@@ -1,4 +1,4 @@
-# $Id: version,v 1.29.134.29 2010/03/04 00:25:25 marka Exp $
+# $Id: version,v 1.29.134.32 2010/11/18 01:34:50 marka Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
@@ -7,4 +7,4 @@ MAJORVER=9
 MINORVER=4
 PATCHVER=
 RELEASETYPE=-ESV
-RELEASEVER=-R1
+RELEASEVER=-R4
@@ -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
 }}}

 ###############################################################################