9.2.4rc7

86 files changed, 13153 insertions, 9461 deletions

diff --git a/CHANGES b/CHANGES
index 21431631..6155ca94 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,4 +1,27 @@
 
+	--- 9.2.4rc7 released ---
+
+1694.	[bug]		Report if the builtin views of "_default" / "_bind"
+			are defined in named.conf. [RT #12023]
+
+1692.	[bug]		Don't set -I, -L and -R flags when libcrypto is in
+			/usr/lib. [RT #11971]
+
+1691.	[bug]		sdb's attachversion was not complete. [RT #11990]
+
+1690.	[bug]		Delay detaching view from the client until UPDATE
+			processing completes when shutting down. [RT #11714]
+
+1689.	[bug]		DNS_NAME_TOREGION() macros contained a gratuitous
+			semicolons. [RT #11707]
+
+1688.	[bug]		LDFLAGS was not supported.
+
+1687.	[bug]		Race condition in dispatch. [RT #10272]
+
+1686.	[bug]		Named sent a extraneous NOTIFY when it received a
+			redundant UPDATE request. [RT #11943]
+
 	--- 9.2.4rc6 released ---
 
 1685.	[bug]		Change #1679 loop tests weren't quite right.
diff --git a/README b/README
index f38dff06..2d5d7d8d 100644
--- a/README
+++ b/README
@@ -242,6 +242,9 @@ Building
 			and SHOULD NOT be set unless you are currently
 			making use of it.
 
+	    LDFLAGS
+		Linker flags. Defaults to empty string.
+
 	To build shared libraries, specify "--with-libtool" on the
 	configure command line.
 
diff --git a/bin/check/Makefile.in b/bin/check/Makefile.in
index 12d8a6f4..c3bec581 100644
--- a/bin/check/Makefile.in
+++ b/bin/check/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.15.2.5 2004/03/09 06:09:08 marka Exp $
+# $Id: Makefile.in,v 1.15.2.6 2004/07/20 07:00:09 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -64,11 +64,11 @@ named-checkzone.@O@: named-checkzone.c
 
 named-checkconf: named-checkconf.@O@ check-tool.@O@ ${ISCDEPLIBS} \
 		 ${ISCCFGDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ named-checkconf.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ named-checkconf.@O@ \
 	check-tool.@O@ ${ISCCFGLIBS} ${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 named-checkzone: named-checkzone.@O@ check-tool.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ named-checkzone.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ named-checkzone.@O@ \
 	check-tool.@O@ ${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 doc man:: ${MANOBJS}
diff --git a/bin/dig/Makefile.in b/bin/dig/Makefile.in
index 885c8526..0e4c407c 100644
--- a/bin/dig/Makefile.in
+++ b/bin/dig/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.25.2.2 2004/03/09 06:09:10 marka Exp $
+# $Id: Makefile.in,v 1.25.2.3 2004/07/20 07:00:09 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -57,13 +57,13 @@ MANOBJS =	${MANPAGES} ${HTMLPAGES}
 @BIND9_MAKE_RULES@
 
 dig: dig.@O@ dighost.@O@ ${UOBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ dig.@O@ dighost.@O@ ${UOBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ dig.@O@ dighost.@O@ ${UOBJS} ${LIBS}
 
 host: host.@O@ dighost.@O@ ${UOBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ host.@O@ dighost.@O@ ${UOBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ host.@O@ dighost.@O@ ${UOBJS} ${LIBS}
 
 nslookup: nslookup.@O@ dighost.@O@ ${UOBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ nslookup.@O@ dighost.@O@ ${UOBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ nslookup.@O@ dighost.@O@ ${UOBJS} ${LIBS}
 
 doc man:: ${MANOBJS}
 
diff --git a/bin/dnssec/Makefile.in b/bin/dnssec/Makefile.in
index 65a0e8c8..6e7fdd05 100644
--- a/bin/dnssec/Makefile.in
+++ b/bin/dnssec/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.19.2.2 2004/03/09 06:09:14 marka Exp $
+# $Id: Makefile.in,v 1.19.2.3 2004/07/20 07:00:10 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -65,19 +65,19 @@ MANOBJS =	${MANPAGES} ${HTMLPAGES}
 @BIND9_MAKE_RULES@
 
 dnssec-keygen: dnssec-keygen.@O@ ${OBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ dnssec-keygen.@O@ ${OBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ dnssec-keygen.@O@ ${OBJS} ${LIBS}
 
 dnssec-makekeyset: dnssec-makekeyset.@O@ ${OBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ dnssec-makekeyset.@O@ ${OBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ dnssec-makekeyset.@O@ ${OBJS} ${LIBS}
 
 dnssec-signkey: dnssec-signkey.@O@ ${OBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ dnssec-signkey.@O@ ${OBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ dnssec-signkey.@O@ ${OBJS} ${LIBS}
 
 dnssec-signzone.@O@: dnssec-signzone.c
 	${LIBTOOL_MODE_COMPILE} ${PURIFY} ${CC} ${ALL_CFLAGS} -DVERSION=\"${VERSION}\" -c $<
 
 dnssec-signzone: dnssec-signzone.@O@ ${OBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ dnssec-signzone.@O@ ${OBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ dnssec-signzone.@O@ ${OBJS} ${LIBS}
 
 doc man:: ${MANOBJS}
 
diff --git a/bin/named/Makefile.in b/bin/named/Makefile.in
index cebe49f0..bb19677c 100644
--- a/bin/named/Makefile.in
+++ b/bin/named/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.74.2.2 2004/03/09 06:09:17 marka Exp $
+# $Id: Makefile.in,v 1.74.2.3 2004/07/20 07:00:10 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -100,7 +100,7 @@ config.@O@: config.c
 		-c ${srcdir}/config.c
 
 named: ${OBJS} ${UOBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ${OBJS} ${UOBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ${OBJS} ${UOBJS} ${LIBS}
 
 lwresd: named
 	rm -f lwresd
diff --git a/bin/named/client.c b/bin/named/client.c
index f40c110a..4074fbd0 100644
--- a/bin/named/client.c
+++ b/bin/named/client.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: client.c,v 1.176.2.15 2004/04/28 14:17:03 marka Exp $ */
+/* $Id: client.c,v 1.176.2.16 2004/07/23 02:56:59 marka Exp $ */
 
 #include <config.h>
 
@@ -218,13 +218,20 @@ exit_check(ns_client_t *client) {
 	 *  - The client does not detach from the view until references is zero
 	 *  - references does not go to zero until the resolver has shut down
 	 *
+	 * Keep the view attached until any outstanding updates complete.
 	 */
-	if (client->newstate == NS_CLIENTSTATE_FREED && client->view != NULL)
+	if (client->nupdates == 0 && 
+	    client->newstate == NS_CLIENTSTATE_FREED && client->view != NULL)
 		dns_view_detach(&client->view);
 
 	if (client->state == NS_CLIENTSTATE_WORKING) {
 		INSIST(client->newstate <= NS_CLIENTSTATE_READING);
 		/*
+		 * Let the update processing complete.
+		 */
+		if (client->nupdates > 0)
+			return (ISC_TRUE);
+		/*
 		 * We are trying to abort request processing.
 		 */
 		if (client->nsends > 0) {
@@ -519,6 +526,7 @@ ns_client_endrequest(ns_client_t *client) {
 	INSIST(client->nreads == 0);
 	INSIST(client->nsends == 0);
 	INSIST(client->nrecvs == 0);
+	INSIST(client->nupdates == 0);
 	INSIST(client->state == NS_CLIENTSTATE_WORKING);
 
 	CTRACE("endrequest");
@@ -1569,6 +1577,7 @@ client_create(ns_clientmgr_t *manager, ns_client_t **clientp)
 	client->nreads = 0;
 	client->nsends = 0;
 	client->nrecvs = 0;
+	client->nupdates = 0;
 	client->nctls = 0;
 	client->references = 0;
 	client->attributes = 0;
diff --git a/bin/named/include/named/client.h b/bin/named/include/named/client.h
index 99008211..3589c5b2 100644
--- a/bin/named/include/named/client.h
+++ b/bin/named/include/named/client.h
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: client.h,v 1.60.2.3 2004/03/09 06:09:21 marka Exp $ */
+/* $Id: client.h,v 1.60.2.4 2004/07/23 02:57:01 marka Exp $ */
 
 #ifndef NAMED_CLIENT_H
 #define NAMED_CLIENT_H 1
@@ -91,6 +91,7 @@ struct ns_client {
 	int			nreads;
 	int			nsends;
 	int			nrecvs;
+	int			nupdates;
 	int			nctls;
 	int			references;
 	unsigned int		attributes;
diff --git a/bin/named/interfacemgr.c b/bin/named/interfacemgr.c
index 24d7aa4f..96b7c749 100644
--- a/bin/named/interfacemgr.c
+++ b/bin/named/interfacemgr.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: interfacemgr.c,v 1.59.2.6 2004/03/09 06:09:18 marka Exp $ */
+/* $Id: interfacemgr.c,v 1.59.2.7 2004/08/10 04:58:00 jinmei Exp $ */
 
 #include <config.h>
 
@@ -348,9 +348,9 @@ ns_interface_setup(ns_interfacemgr_t *mgr, isc_sockaddr_t *addr,
 	if (result != ISC_R_SUCCESS) {
 		/*
 		 * XXXRTH We don't currently have a way to easily stop dispatch
-		 * service, so we return currently return ISC_R_SUCCESS (the
-		 * UDP stuff will work even if TCP creation failed).  This will
-		 * be fixed later.
+		 * service, so we currently return ISC_R_SUCCESS (the UDP stuff
+		 * will work even if TCP creation failed).  This will be fixed
+		 * later.
 		 */
 		result = ISC_R_SUCCESS;
 	}
diff --git a/bin/named/update.c b/bin/named/update.c
index 22829183..439e52f9 100644
--- a/bin/named/update.c
+++ b/bin/named/update.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: update.c,v 1.88.2.11 2004/06/20 23:44:35 marka Exp $ */
+/* $Id: update.c,v 1.88.2.13 2004/07/23 02:57:00 marka Exp $ */
 
 #include <config.h>
 
@@ -1893,6 +1893,8 @@ send_update_event(ns_client_t *client, dns_zone_t *zone) {
 
 	evclient = NULL;
 	ns_client_attach(client, &evclient);
+	INSIST(client->nupdates == 0);
+	client->nupdates++;
 	event->ev_arg = evclient;
 
 	dns_zone_gettask(zone, &zonetask);
@@ -2456,26 +2458,29 @@ update_action(isc_task_t *task, isc_event_t *event) {
 
 			dns_journal_destroy(&journal);
 		}
-	}
 
-	/*
-	 * XXXRTH  Just a note that this committing code will have to change
-	 *         to handle databases that need two-phase commit, but this
-	 *	   isn't a priority.
-	 */
-	update_log(client, zone, LOGLEVEL_DEBUG,
-		   "committing update transaction");
-	dns_db_closeversion(db, &ver, ISC_TRUE);
+		/*
+		 * XXXRTH  Just a note that this committing code will have
+		 *	   to change to handle databases that need two-phase
+		 *	   commit, but this isn't a priority.
+		 */
+		update_log(client, zone, LOGLEVEL_DEBUG,
+			   "committing update transaction");
+		dns_db_closeversion(db, &ver, ISC_TRUE);
 
-	/*
-	 * Mark the zone as dirty so that it will be written to disk.
-	 */
-	dns_zone_markdirty(zone);
+		/*
+		 * Mark the zone as dirty so that it will be written to disk.
+		 */
+		dns_zone_markdirty(zone);
 
-	/*
-	 * Notify slaves of the change we just made.
-	 */
-	dns_zone_notify(zone);
+		/*
+		 * Notify slaves of the change we just made.
+		 */
+		dns_zone_notify(zone);
+	} else {
+		update_log(client, zone, LOGLEVEL_DEBUG, "redundant request");
+		dns_db_closeversion(db, &ver, ISC_TRUE);
+	}
 	result = ISC_R_SUCCESS;
 	goto common;
 
@@ -2523,6 +2528,8 @@ updatedone_action(isc_task_t *task, isc_event_t *event) {
 	INSIST(event->ev_type == DNS_EVENT_UPDATEDONE);
 	INSIST(task == client->task);
 
+	INSIST(client->nupdates > 0);
+	client->nupdates--;
 	respond(client, uev->result);
 	ns_client_detach(&client);
 	isc_event_free(&event);
@@ -2538,6 +2545,8 @@ forward_fail(isc_task_t *task, isc_event_t *event) {
 
 	UNUSED(task);
 
+	INSIST(client->nupdates > 0);
+	client->nupdates--;
 	respond(client, DNS_R_SERVFAIL);
 	ns_client_detach(&client);
 	isc_event_free(&event);
@@ -2568,6 +2577,8 @@ forward_done(isc_task_t *task, isc_event_t *event) {
 
 	UNUSED(task);
 
+	INSIST(client->nupdates > 0);
+	client->nupdates--;
 	ns_client_sendraw(client, uev->answer);
 	dns_message_destroy(&uev->answer);
 	isc_event_free(&event);
@@ -2609,6 +2620,8 @@ send_forward_event(ns_client_t *client, dns_zone_t *zone) {
 
 	evclient = NULL;
 	ns_client_attach(client, &evclient);
+	INSIST(client->nupdates == 0);
+	client->nupdates++;
 	event->ev_arg = evclient;
 
 	dns_zone_gettask(zone, &zonetask);
diff --git a/bin/nsupdate/Makefile.in b/bin/nsupdate/Makefile.in
index 7bca0cfb..7cbf59e6 100644
--- a/bin/nsupdate/Makefile.in
+++ b/bin/nsupdate/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.15.2.2 2004/03/09 06:09:25 marka Exp $
+# $Id: Makefile.in,v 1.15.2.3 2004/07/20 07:00:10 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -59,7 +59,7 @@ MANOBJS =	${MANPAGES} ${HTMLPAGES}
 @BIND9_MAKE_RULES@
 
 nsupdate: nsupdate.@O@ ${UOBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ nsupdate.@O@ ${UOBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ nsupdate.@O@ ${UOBJS} ${LIBS}
 
 doc man:: ${MANOBJS}
 
diff --git a/bin/rndc/Makefile.in b/bin/rndc/Makefile.in
index 7185ef36..e0efefd5 100644
--- a/bin/rndc/Makefile.in
+++ b/bin/rndc/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.32.2.5 2004/03/09 06:09:26 marka Exp $
+# $Id: Makefile.in,v 1.32.2.6 2004/07/20 07:00:12 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -72,11 +72,11 @@ rndc-confgen.@O@: rndc-confgen.c
 		-c ${srcdir}/rndc-confgen.c
 
 rndc: rndc.@O@ util.@O@ ${RNDCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ rndc.@O@ util.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rndc.@O@ util.@O@ \
 		${RNDCLIBS}
 
 rndc-confgen: rndc-confgen.@O@ util.@O@ ${UOBJS} ${CONFDEPLIBS} 
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ rndc-confgen.@O@ util.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rndc-confgen.@O@ util.@O@ \
 		${UOBJS} ${CONFLIBS}
 
 doc man:: ${MANOBJS}
diff --git a/bin/tests/Makefile.in b/bin/tests/Makefile.in
index 71acd45b..73ab2cd7 100644
--- a/bin/tests/Makefile.in
+++ b/bin/tests/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.113.2.3 2004/03/09 06:09:29 marka Exp $
+# $Id: Makefile.in,v 1.113.2.4 2004/07/20 07:00:12 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -133,154 +133,154 @@ SRCS =		adb_test.c \
 all_tests: ${XTARGETS}
 
 genrandom: genrandom.@O@
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ genrandom.@O@
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ genrandom.@O@
 
 adb_test: adb_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ adb_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ adb_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 nxtify: nxtify.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ nxtify.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ nxtify.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 byaddr_test: byaddr_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ byaddr_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ byaddr_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 byname_test: byname_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ byname_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ byname_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 lex_test: lex_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ lex_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ lex_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 lfsr_test: lfsr_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ lfsr_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ lfsr_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 log_test: log_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ log_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ log_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 name_test: name_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ name_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ name_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 hash_test: hash_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ hash_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ hash_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 entropy_test: entropy_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ entropy_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ entropy_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 entropy2_test: entropy2_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ entropy2_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ entropy2_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 sock_test: sock_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ sock_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ sock_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 sym_test: sym_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ sym_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ sym_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 task_test: task_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ task_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ task_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 shutdown_test: shutdown_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ shutdown_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ shutdown_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 timer_test: timer_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ timer_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ timer_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 ratelimiter_test: ratelimiter_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ratelimiter_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ratelimiter_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 rbt_test: rbt_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ rbt_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rbt_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 rdata_test: rdata_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ rdata_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rdata_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 rwlock_test: rwlock_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ rwlock_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ rwlock_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 wire_test: wire_test.@O@ printmsg.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ wire_test.@O@ printmsg.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ wire_test.@O@ printmsg.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 master_test: master_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ master_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ master_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 db_test: db_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ db_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ db_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 compress_test: compress_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ compress_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ compress_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 mempool_test: mempool_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ mempool_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ mempool_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 serial_test: serial_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ serial_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ serial_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 zone_test: zone_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ zone_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ zone_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 fsaccess_test: fsaccess_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ fsaccess_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ fsaccess_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 inter_test: inter_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ inter_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ inter_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 keyboard_test: keyboard_test.@O@ ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ keyboard_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ keyboard_test.@O@ \
 		${ISCLIBS} ${LIBS}
 
 lwresconf_test: lwresconf_test.@O@ ${ISCDEPLIBS} ${LWRESDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ lwresconf_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ lwresconf_test.@O@ \
 		${LWRESLIBS} ${ISCLIBS} ${LIBS}
 
 lwres_test: lwres_test.@O@ ${ISCDEPLIBS} ${LWRESDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ lwres_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ lwres_test.@O@ \
 		${LWRESLIBS} ${ISCLIBS} ${LIBS}
 
 gxbn_test: gxbn_test.@O@ ${LWRESDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ gxbn_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ gxbn_test.@O@ \
 		${LWRESLIBS} ${ISCLIBS} ${LIBS}
 
 gxba_test: gxba_test.@O@ ${LWRESDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ gxba_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ gxba_test.@O@ \
 		${LWRESLIBS} ${ISCLIBS} ${LIBS}
 
 sig0_test: sig0_test.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ sig0_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ sig0_test.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 journalprint: journalprint.@O@ ${ISCDEPLIBS} ${DNSDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ journalprint.@O@ \
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ journalprint.@O@ \
 		${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 cfg_test: cfg_test.@O@ ${ISCCFGDEPLIBS} ${DNSDEPLIBS} ${ISCDEPLIBS}
-	${LIBTOOL_MODE_LINK} ${CC} ${CFLAGS} -o $@ cfg_test.@O@ \
+	${LIBTOOL_MODE_LINK} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ cfg_test.@O@ \
 		${ISCCFGLIBS} ${DNSLIBS} ${ISCLIBS} ${LIBS}
 
 distclean::
diff --git a/bin/tests/db/Makefile.in b/bin/tests/db/Makefile.in
index 79828890..62d6b5c0 100644
--- a/bin/tests/db/Makefile.in
+++ b/bin/tests/db/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.21.2.2 2004/03/09 06:09:36 marka Exp $
+# $Id: Makefile.in,v 1.21.2.3 2004/07/20 07:00:12 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -45,7 +45,7 @@ TARGETS =	t_db
 @BIND9_MAKE_RULES@
 
 t_db: t_db.@O@ ${DEPLIBS} ${TLIB}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_db.@O@ ${TLIB} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_db.@O@ ${TLIB} ${LIBS}
 
 test: t_db
 	-@./t_db -c @top_srcdir@/t_config -b @srcdir@ -a
diff --git a/bin/tests/dst/Makefile.in b/bin/tests/dst/Makefile.in
index 15417d89..4238027b 100644
--- a/bin/tests/dst/Makefile.in
+++ b/bin/tests/dst/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.30.2.2 2004/03/09 06:09:36 marka Exp $
+# $Id: Makefile.in,v 1.30.2.3 2004/07/20 07:00:13 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -45,10 +45,10 @@ SRCS =		dst_test.c t_dst.c
 @BIND9_MAKE_RULES@
 
 dst_test: dst_test.@O@ ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ dst_test.@O@ ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ dst_test.@O@ ${LIBS}
 
 t_dst: t_dst.@O@ ${DEPLIBS} ${TLIB}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_dst.@O@  ${TLIB} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_dst.@O@  ${TLIB} ${LIBS}
 
 test: t_dst
 	../genrandom 100 randomfile
diff --git a/bin/tests/master/Makefile.in b/bin/tests/master/Makefile.in
index 2e712dd9..ff78518e 100644
--- a/bin/tests/master/Makefile.in
+++ b/bin/tests/master/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.20.2.2 2004/03/09 06:09:37 marka Exp $
+# $Id: Makefile.in,v 1.20.2.3 2004/07/20 07:00:13 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -46,7 +46,7 @@ SRCS =		t_master.c
 @BIND9_MAKE_RULES@
 
 t_master: t_master.@O@ ${DEPLIBS} ${TLIB}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_master.@O@ ${TLIB} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_master.@O@ ${TLIB} ${LIBS}
 
 test: t_master
 	-@ ./t_master -c @top_srcdir@/t_config -b @srcdir@ -a
diff --git a/bin/tests/mem/Makefile.in b/bin/tests/mem/Makefile.in
index 52221fc0..80a647a9 100644
--- a/bin/tests/mem/Makefile.in
+++ b/bin/tests/mem/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.25.2.2 2004/03/09 06:09:37 marka Exp $
+# $Id: Makefile.in,v 1.25.2.3 2004/07/20 07:00:14 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -43,7 +43,7 @@ SRCS =		t_mem.c
 @BIND9_MAKE_RULES@
 
 t_mem: t_mem.@O@ ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_mem.@O@ ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_mem.@O@ ${LIBS}
 
 test: t_mem
 	-@./t_mem -b @srcdir@ -q 300 -a
diff --git a/bin/tests/names/Makefile.in b/bin/tests/names/Makefile.in
index 7af437d6..f7b67bc6 100644
--- a/bin/tests/names/Makefile.in
+++ b/bin/tests/names/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.20.2.2 2004/03/09 06:09:38 marka Exp $
+# $Id: Makefile.in,v 1.20.2.3 2004/07/20 07:00:14 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -46,7 +46,7 @@ SRCS =		t_names.c
 @BIND9_MAKE_RULES@
 
 t_names: t_names.@O@ ${DEPLIBS} ${TLIB}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_names.@O@ ${TLIB} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_names.@O@ ${TLIB} ${LIBS}
 
 test: t_names
 	-@./t_names -c @top_srcdir@/t_config -b @srcdir@ -a
diff --git a/bin/tests/net/Makefile.in b/bin/tests/net/Makefile.in
index 4fae436f..bff2a92b 100644
--- a/bin/tests/net/Makefile.in
+++ b/bin/tests/net/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.9.2.2 2004/03/09 06:09:38 marka Exp $
+# $Id: Makefile.in,v 1.9.2.3 2004/07/20 07:00:14 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -43,7 +43,7 @@ OBJS =		driver.@O@ netaddr_multicast.@O@ sockaddr_multicast.@O@
 @BIND9_MAKE_RULES@
 
 t_net: ${OBJS} ${DEPLIBS} ${TLIB}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ${OBJS} ${TLIB} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ${OBJS} ${TLIB} ${LIBS}
 
 test: t_net
 	-@./t_net
diff --git a/bin/tests/rbt/Makefile.in b/bin/tests/rbt/Makefile.in
index 955b8341..07f946bd 100644
--- a/bin/tests/rbt/Makefile.in
+++ b/bin/tests/rbt/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.20.2.2 2004/03/09 06:09:39 marka Exp $
+# $Id: Makefile.in,v 1.20.2.3 2004/07/20 07:00:15 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -46,7 +46,7 @@ SRCS =		t_rbt.c
 @BIND9_MAKE_RULES@
 
 t_rbt: t_rbt.@O@ ${DEPLIBS} ${TLIB}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_rbt.@O@ ${TLIB} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_rbt.@O@ ${TLIB} ${LIBS}
 
 test: t_rbt
 	-@./t_rbt -c @top_srcdir@/t_config -b @srcdir@ -a
diff --git a/bin/tests/sockaddr/Makefile.in b/bin/tests/sockaddr/Makefile.in
index 028f4930..d582ea56 100644
--- a/bin/tests/sockaddr/Makefile.in
+++ b/bin/tests/sockaddr/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.14.2.2 2004/03/09 06:09:40 marka Exp $
+# $Id: Makefile.in,v 1.14.2.3 2004/07/20 07:00:15 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -43,7 +43,7 @@ SRCS =		t_sockaddr.c
 @BIND9_MAKE_RULES@
 
 t_sockaddr: t_sockaddr.@O@ ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_sockaddr.@O@ ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_sockaddr.@O@ ${LIBS}
 
 test: t_sockaddr
 	-@./t_sockaddr -b @srcdir@ -a
diff --git a/bin/tests/system/lwresd/Makefile.in b/bin/tests/system/lwresd/Makefile.in
index 4c58c35b..21a82bda 100644
--- a/bin/tests/system/lwresd/Makefile.in
+++ b/bin/tests/system/lwresd/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.12.2.2 2004/03/09 06:09:59 marka Exp $
+# $Id: Makefile.in,v 1.12.2.3 2004/07/20 07:00:16 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -49,7 +49,7 @@ SRCS =		lwtest.c
 all: lwtest
 
 lwtest: ${OBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ${OBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ${OBJS} ${LIBS}
 
 clean distclean::
 	rm -f ${TARGETS}
diff --git a/bin/tests/system/tkey/Makefile.in b/bin/tests/system/tkey/Makefile.in
index e45e07c1..bfd5cd8a 100644
--- a/bin/tests/system/tkey/Makefile.in
+++ b/bin/tests/system/tkey/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.3.2.2 2004/03/09 06:10:18 marka Exp $
+# $Id: Makefile.in,v 1.3.2.3 2004/07/20 07:00:16 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -50,10 +50,10 @@ SRCS =		keycreate.c keydelete.c
 all: keycreate keydelete
 
 keycreate: ${CREATEOBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ${CREATEOBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ${CREATEOBJS} ${LIBS}
 
 keydelete: ${DELETEOBJS} ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ ${DELETEOBJS} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ ${DELETEOBJS} ${LIBS}
 
 clean distclean::
 	rm -f ${TARGETS}
diff --git a/bin/tests/tasks/Makefile.in b/bin/tests/tasks/Makefile.in
index 18261ae1..baafff55 100644
--- a/bin/tests/tasks/Makefile.in
+++ b/bin/tests/tasks/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.23.2.2 2004/03/09 06:10:30 marka Exp $
+# $Id: Makefile.in,v 1.23.2.3 2004/07/20 07:00:16 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -43,7 +43,7 @@ SRCS =		t_tasks.c
 @BIND9_MAKE_RULES@
 
 t_tasks: t_tasks.@O@ ${DEPLIBS}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_tasks.@O@ ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_tasks.@O@ ${LIBS}
 
 test: t_tasks
 	-@./t_tasks -c @top_srcdir@/t_config -b @srcdir@ -a
diff --git a/bin/tests/timers/Makefile.in b/bin/tests/timers/Makefile.in
index fc4d8ce4..a2b8f4e1 100644
--- a/bin/tests/timers/Makefile.in
+++ b/bin/tests/timers/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.21.2.2 2004/03/09 06:10:31 marka Exp $
+# $Id: Makefile.in,v 1.21.2.3 2004/07/20 07:00:17 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -43,7 +43,7 @@ SRCS =		t_timers.c
 @BIND9_MAKE_RULES@
 
 t_timers: t_timers.@O@ ${DEPLIBS} ${TLIB}
-	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} -o $@ t_timers.@O@ ${TLIB} ${LIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ t_timers.@O@ ${TLIB} ${LIBS}
 
 test: t_timers
 	-@./t_timers -c @top_srcdir@/t_config -b @srcdir@ -q 60 -a
diff --git a/configure b/configure
index 383449ba..4fcaae1f 100755
--- a/configure
+++ b/configure
@@ -1,5 +1,5 @@
 #! /bin/sh
-# From configure.in Revision: 1.294.2.32 .
+# From configure.in Revision: 1.294.2.33 .
 # Guess values for system-dependent variables and create Makefiles.
 # Generated by GNU Autoconf 2.59.
 #
@@ -4544,15 +4544,21 @@ echo "$as_me: error: OpenSSL was not found in any of $openssldirs; use --with-op
 			fi
 		fi
 		USE_OPENSSL='-DOPENSSL'
-		DST_OPENSSL_INC="-I$use_openssl/include"
-		case $host in
-		*-solaris*)
-			DNS_OPENSSL_LIBS="-L$use_openssl/lib -R$use_openssl/lib -lcrypto"
-			;;
-		*)
-			DNS_OPENSSL_LIBS="-L$use_openssl/lib -lcrypto"
-			;;
-		esac
+		if test "$use_openssl" = "/usr"
+		then
+			DST_OPENSSL_INC=""
+			DNS_OPENSSL_LIBS="-lcrypto"
+		else
+			DST_OPENSSL_INC="-I$use_openssl/include"
+			case $host in
+			*-solaris*)
+				DNS_OPENSSL_LIBS="-L$use_openssl/lib -R$use_openssl/lib -lcrypto"
+				;;
+			*)
+				DNS_OPENSSL_LIBS="-L$use_openssl/lib -lcrypto"
+				;;
+			esac
+		fi
 		echo "$as_me:$LINENO: result: using openssl from $use_openssl/lib and $use_openssl/include" >&5
 echo "${ECHO_T}using openssl from $use_openssl/lib and $use_openssl/include" >&6
 
@@ -7674,7 +7680,7 @@ ia64-*-hpux*)
   ;;
 *-*-irix6*)
   # Find out which ABI we are using.
-  echo '#line 7677 "configure"' > conftest.$ac_ext
+  echo '#line 7683 "configure"' > conftest.$ac_ext
   if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
   (eval $ac_compile) 2>&5
   ac_status=$?
@@ -8664,7 +8670,7 @@ fi
 
 
 # Provide some information about the compiler.
-echo "$as_me:8667:" \
+echo "$as_me:8673:" \
      "checking for Fortran 77 compiler version" >&5
 ac_compiler=`set X $ac_compile; echo $2`
 { (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5
@@ -9702,11 +9708,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:9705: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:9711: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:9709: \$? = $ac_status" >&5
+   echo "$as_me:9715: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -9935,11 +9941,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:9938: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:9944: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:9942: \$? = $ac_status" >&5
+   echo "$as_me:9948: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -9995,11 +10001,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:9998: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:10004: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:10002: \$? = $ac_status" >&5
+   echo "$as_me:10008: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -12179,7 +12185,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 12182 "configure"
+#line 12188 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -12277,7 +12283,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 12280 "configure"
+#line 12286 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -14460,11 +14466,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:14463: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:14469: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:14467: \$? = $ac_status" >&5
+   echo "$as_me:14473: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -14520,11 +14526,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:14523: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:14529: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:14527: \$? = $ac_status" >&5
+   echo "$as_me:14533: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -15881,7 +15887,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 15884 "configure"
+#line 15890 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -15979,7 +15985,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 15982 "configure"
+#line 15988 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -16806,11 +16812,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:16809: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:16815: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:16813: \$? = $ac_status" >&5
+   echo "$as_me:16819: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -16866,11 +16872,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:16869: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:16875: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:16873: \$? = $ac_status" >&5
+   echo "$as_me:16879: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -18904,11 +18910,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:18907: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:18913: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:18911: \$? = $ac_status" >&5
+   echo "$as_me:18917: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -19137,11 +19143,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:19140: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:19146: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:19144: \$? = $ac_status" >&5
+   echo "$as_me:19150: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -19197,11 +19203,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:19200: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:19206: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:19204: \$? = $ac_status" >&5
+   echo "$as_me:19210: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -21381,7 +21387,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 21384 "configure"
+#line 21390 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -21479,7 +21485,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 21482 "configure"
+#line 21488 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/configure.in b/configure.in
index 6bf24fd0..744e12ba 100644
--- a/configure.in
+++ b/configure.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-AC_REVISION($Revision: 1.294.2.32 $)
+AC_REVISION($Revision: 1.294.2.33 $)
 
 AC_INIT(lib/dns/name.c)
 AC_PREREQ(2.13)
@@ -335,15 +335,21 @@ case "$use_openssl" in
 			fi
 		fi
 		USE_OPENSSL='-DOPENSSL'
-		DST_OPENSSL_INC="-I$use_openssl/include"
-		case $host in
-		*-solaris*)
-			DNS_OPENSSL_LIBS="-L$use_openssl/lib -R$use_openssl/lib -lcrypto"
-			;;
-		*)
-			DNS_OPENSSL_LIBS="-L$use_openssl/lib -lcrypto"
-			;;
-		esac
+		if test "$use_openssl" = "/usr"
+		then
+			DST_OPENSSL_INC=""
+			DNS_OPENSSL_LIBS="-lcrypto"
+		else
+			DST_OPENSSL_INC="-I$use_openssl/include"
+			case $host in
+			*-solaris*)
+				DNS_OPENSSL_LIBS="-L$use_openssl/lib -R$use_openssl/lib -lcrypto"
+				;;
+			*)
+				DNS_OPENSSL_LIBS="-L$use_openssl/lib -lcrypto"
+				;;
+			esac
+		fi
 		AC_MSG_RESULT(using openssl from $use_openssl/lib and $use_openssl/include)
 
 		saved_cflags="$CFLAGS"
diff --git a/contrib/idn/idnkit-1.0-src/lib/Makefile.in b/contrib/idn/idnkit-1.0-src/lib/Makefile.in
index 76f703ca..c21e8688 100644
--- a/contrib/idn/idnkit-1.0-src/lib/Makefile.in
+++ b/contrib/idn/idnkit-1.0-src/lib/Makefile.in
@@ -1,4 +1,4 @@
-# $Id: Makefile.in,v 1.1.1.1 2003/06/04 00:25:47 marka Exp $
+# $Id: Makefile.in,v 1.1.1.1.10.1 2004/07/20 07:00:17 marka Exp $
 # Copyright (c) 2000, 2002 Japan Network Information Center.
 # All rights reserved.
 #  
@@ -189,7 +189,7 @@ SAMPLES = idn.conf.sample idnalias.conf.sample
 	$(LIBTOOL) --mode=compile $(CC) $(CFLAGS) -c $<
 
 .c.to:
-	$(CC) -o $@ -DTEST $(CFLAGS) -c $<
+	$(CC) -o $@ -DTEST $(CFLAGS) $(LDFLAGS) -c $<
 
 all: all-localdir all-subdirs
 @LITEONLY_TRUE@all-localdir: $(LITELIB).la $(SAMPLES)
diff --git a/contrib/idn/idnkit-1.0-src/lib/tests/Makefile.in b/contrib/idn/idnkit-1.0-src/lib/tests/Makefile.in
index ef73d032..ef6577d1 100644
--- a/contrib/idn/idnkit-1.0-src/lib/tests/Makefile.in
+++ b/contrib/idn/idnkit-1.0-src/lib/tests/Makefile.in
@@ -1,4 +1,4 @@
-# $Id: Makefile.in,v 1.1.1.1 2003/06/04 00:26:46 marka Exp $
+# $Id: Makefile.in,v 1.1.1.1.10.1 2004/07/20 07:00:17 marka Exp $
 # Copyright (c) 2000, 2002 Japan Network Information Center.
 # All rights reserved.
 #  
@@ -300,5 +300,5 @@ testconfig.h: ../../include/config.h
 		../../include/config.h > testconfig.h
 
 iconvchk: iconvchk.c codeset.h
-	$(LIBTOOL) --mode=link $(CC) $(CFLAGS) -o $@ \
+	$(LIBTOOL) --mode=link $(CC) $(CFLAGS) $(LDFLAGS) -o $@ \
 		$(srcdir)/iconvchk.c $(IDNLIB) $(ICONVLIB)
diff --git a/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.2.4-patch b/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.2.4-patch
index 8a40759e..eee1a9ce 100644
--- a/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.2.4-patch
+++ b/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.2.4-patch
@@ -17,8 +17,8 @@ and install.
 
 
 Index: README.idnkit
---- /dev/null	Thu Jul  1 13:17:02 2004
-+++ README.idnkit	Thu Jul  1 13:19:01 2004
+--- /dev/null	Wed Aug 11 15:47:58 2004
++++ README.idnkit	Wed Aug 11 15:34:45 2004
 @@ -0,0 +1,113 @@
 +
 +			BIND-9 IDN patch
@@ -136,10 +136,10 @@ Index: README.idnkit
 Index: configure
 ===================================================================
 RCS file: /proj/cvs/prod/bind9/configure,v
-retrieving revision 1.284.2.29
-diff -U2 -r1.284.2.29 configure
---- configure	1 Jul 2004 00:18:29 -0000	1.284.2.29
-+++ configure	1 Jul 2004 03:21:53 -0000
+retrieving revision 1.284.2.30
+diff -U2 -r1.284.2.30 configure
+--- configure	23 Jul 2004 04:44:06 -0000	1.284.2.30
++++ configure	11 Aug 2004 05:49:51 -0000
 @@ -466,5 +466,5 @@
  #endif"
  
@@ -156,183 +156,183 @@ diff -U2 -r1.284.2.29 configure
 +  --with-idnlib=ARG    specify libidnkit
  
  Some influential environment variables:
-@@ -7675,5 +7679,5 @@
+@@ -7681,5 +7685,5 @@
  *-*-irix6*)
    # Find out which ABI we are using.
--  echo '#line 7677 "configure"' > conftest.$ac_ext
-+  echo '#line 7681 "configure"' > conftest.$ac_ext
+-  echo '#line 7683 "configure"' > conftest.$ac_ext
++  echo '#line 7687 "configure"' > conftest.$ac_ext
    if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
    (eval $ac_compile) 2>&5
-@@ -8665,5 +8669,5 @@
+@@ -8671,5 +8675,5 @@
  
  # Provide some information about the compiler.
--echo "$as_me:8667:" \
-+echo "$as_me:8671:" \
+-echo "$as_me:8673:" \
++echo "$as_me:8677:" \
       "checking for Fortran 77 compiler version" >&5
  ac_compiler=`set X $ac_compile; echo $2`
-@@ -9703,9 +9707,9 @@
+@@ -9709,9 +9713,9 @@
     -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
     -e 's:$: $lt_compiler_flag:'`
--   (eval echo "\"\$as_me:9705: $lt_compile\"" >&5)
-+   (eval echo "\"\$as_me:9709: $lt_compile\"" >&5)
+-   (eval echo "\"\$as_me:9711: $lt_compile\"" >&5)
++   (eval echo "\"\$as_me:9715: $lt_compile\"" >&5)
     (eval "$lt_compile" 2>conftest.err)
     ac_status=$?
     cat conftest.err >&5
--   echo "$as_me:9709: \$? = $ac_status" >&5
-+   echo "$as_me:9713: \$? = $ac_status" >&5
+-   echo "$as_me:9715: \$? = $ac_status" >&5
++   echo "$as_me:9719: \$? = $ac_status" >&5
     if (exit $ac_status) && test -s "$ac_outfile"; then
       # The compiler can only warn and ignore the option if not recognized
-@@ -9936,9 +9940,9 @@
+@@ -9942,9 +9946,9 @@
     -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
     -e 's:$: $lt_compiler_flag:'`
--   (eval echo "\"\$as_me:9938: $lt_compile\"" >&5)
-+   (eval echo "\"\$as_me:9942: $lt_compile\"" >&5)
+-   (eval echo "\"\$as_me:9944: $lt_compile\"" >&5)
++   (eval echo "\"\$as_me:9948: $lt_compile\"" >&5)
     (eval "$lt_compile" 2>conftest.err)
     ac_status=$?
     cat conftest.err >&5
--   echo "$as_me:9942: \$? = $ac_status" >&5
-+   echo "$as_me:9946: \$? = $ac_status" >&5
+-   echo "$as_me:9948: \$? = $ac_status" >&5
++   echo "$as_me:9952: \$? = $ac_status" >&5
     if (exit $ac_status) && test -s "$ac_outfile"; then
       # The compiler can only warn and ignore the option if not recognized
-@@ -9996,9 +10000,9 @@
+@@ -10002,9 +10006,9 @@
     -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
     -e 's:$: $lt_compiler_flag:'`
--   (eval echo "\"\$as_me:9998: $lt_compile\"" >&5)
-+   (eval echo "\"\$as_me:10002: $lt_compile\"" >&5)
+-   (eval echo "\"\$as_me:10004: $lt_compile\"" >&5)
++   (eval echo "\"\$as_me:10008: $lt_compile\"" >&5)
     (eval "$lt_compile" 2>out/conftest.err)
     ac_status=$?
     cat out/conftest.err >&5
--   echo "$as_me:10002: \$? = $ac_status" >&5
-+   echo "$as_me:10006: \$? = $ac_status" >&5
+-   echo "$as_me:10008: \$? = $ac_status" >&5
++   echo "$as_me:10012: \$? = $ac_status" >&5
     if (exit $ac_status) && test -s out/conftest2.$ac_objext
     then
-@@ -12180,5 +12184,5 @@
+@@ -12186,5 +12190,5 @@
    lt_status=$lt_dlunknown
    cat > conftest.$ac_ext <<EOF
--#line 12182 "configure"
-+#line 12186 "configure"
+-#line 12188 "configure"
++#line 12192 "configure"
  #include "confdefs.h"
  
-@@ -12278,5 +12282,5 @@
+@@ -12284,5 +12288,5 @@
    lt_status=$lt_dlunknown
    cat > conftest.$ac_ext <<EOF
--#line 12280 "configure"
-+#line 12284 "configure"
+-#line 12286 "configure"
++#line 12290 "configure"
  #include "confdefs.h"
  
-@@ -14461,9 +14465,9 @@
+@@ -14467,9 +14471,9 @@
     -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
     -e 's:$: $lt_compiler_flag:'`
--   (eval echo "\"\$as_me:14463: $lt_compile\"" >&5)
-+   (eval echo "\"\$as_me:14467: $lt_compile\"" >&5)
+-   (eval echo "\"\$as_me:14469: $lt_compile\"" >&5)
++   (eval echo "\"\$as_me:14473: $lt_compile\"" >&5)
     (eval "$lt_compile" 2>conftest.err)
     ac_status=$?
     cat conftest.err >&5
--   echo "$as_me:14467: \$? = $ac_status" >&5
-+   echo "$as_me:14471: \$? = $ac_status" >&5
+-   echo "$as_me:14473: \$? = $ac_status" >&5
++   echo "$as_me:14477: \$? = $ac_status" >&5
     if (exit $ac_status) && test -s "$ac_outfile"; then
       # The compiler can only warn and ignore the option if not recognized
-@@ -14521,9 +14525,9 @@
+@@ -14527,9 +14531,9 @@
     -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
     -e 's:$: $lt_compiler_flag:'`
--   (eval echo "\"\$as_me:14523: $lt_compile\"" >&5)
-+   (eval echo "\"\$as_me:14527: $lt_compile\"" >&5)
+-   (eval echo "\"\$as_me:14529: $lt_compile\"" >&5)
++   (eval echo "\"\$as_me:14533: $lt_compile\"" >&5)
     (eval "$lt_compile" 2>out/conftest.err)
     ac_status=$?
     cat out/conftest.err >&5
--   echo "$as_me:14527: \$? = $ac_status" >&5
-+   echo "$as_me:14531: \$? = $ac_status" >&5
+-   echo "$as_me:14533: \$? = $ac_status" >&5
++   echo "$as_me:14537: \$? = $ac_status" >&5
     if (exit $ac_status) && test -s out/conftest2.$ac_objext
     then
-@@ -15882,5 +15886,5 @@
+@@ -15888,5 +15892,5 @@
    lt_status=$lt_dlunknown
    cat > conftest.$ac_ext <<EOF
--#line 15884 "configure"
-+#line 15888 "configure"
+-#line 15890 "configure"
++#line 15894 "configure"
  #include "confdefs.h"
  
-@@ -15980,5 +15984,5 @@
+@@ -15986,5 +15990,5 @@
    lt_status=$lt_dlunknown
    cat > conftest.$ac_ext <<EOF
--#line 15982 "configure"
-+#line 15986 "configure"
+-#line 15988 "configure"
++#line 15992 "configure"
  #include "confdefs.h"
  
-@@ -16807,9 +16811,9 @@
+@@ -16813,9 +16817,9 @@
     -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
     -e 's:$: $lt_compiler_flag:'`
--   (eval echo "\"\$as_me:16809: $lt_compile\"" >&5)
-+   (eval echo "\"\$as_me:16813: $lt_compile\"" >&5)
+-   (eval echo "\"\$as_me:16815: $lt_compile\"" >&5)
++   (eval echo "\"\$as_me:16819: $lt_compile\"" >&5)
     (eval "$lt_compile" 2>conftest.err)
     ac_status=$?
     cat conftest.err >&5
--   echo "$as_me:16813: \$? = $ac_status" >&5
-+   echo "$as_me:16817: \$? = $ac_status" >&5
+-   echo "$as_me:16819: \$? = $ac_status" >&5
++   echo "$as_me:16823: \$? = $ac_status" >&5
     if (exit $ac_status) && test -s "$ac_outfile"; then
       # The compiler can only warn and ignore the option if not recognized
-@@ -16867,9 +16871,9 @@
+@@ -16873,9 +16877,9 @@
     -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
     -e 's:$: $lt_compiler_flag:'`
--   (eval echo "\"\$as_me:16869: $lt_compile\"" >&5)
-+   (eval echo "\"\$as_me:16873: $lt_compile\"" >&5)
+-   (eval echo "\"\$as_me:16875: $lt_compile\"" >&5)
++   (eval echo "\"\$as_me:16879: $lt_compile\"" >&5)
     (eval "$lt_compile" 2>out/conftest.err)
     ac_status=$?
     cat out/conftest.err >&5
--   echo "$as_me:16873: \$? = $ac_status" >&5
-+   echo "$as_me:16877: \$? = $ac_status" >&5
+-   echo "$as_me:16879: \$? = $ac_status" >&5
++   echo "$as_me:16883: \$? = $ac_status" >&5
     if (exit $ac_status) && test -s out/conftest2.$ac_objext
     then
-@@ -18905,9 +18909,9 @@
+@@ -18911,9 +18915,9 @@
     -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
     -e 's:$: $lt_compiler_flag:'`
--   (eval echo "\"\$as_me:18907: $lt_compile\"" >&5)
-+   (eval echo "\"\$as_me:18911: $lt_compile\"" >&5)
+-   (eval echo "\"\$as_me:18913: $lt_compile\"" >&5)
++   (eval echo "\"\$as_me:18917: $lt_compile\"" >&5)
     (eval "$lt_compile" 2>conftest.err)
     ac_status=$?
     cat conftest.err >&5
--   echo "$as_me:18911: \$? = $ac_status" >&5
-+   echo "$as_me:18915: \$? = $ac_status" >&5
+-   echo "$as_me:18917: \$? = $ac_status" >&5
++   echo "$as_me:18921: \$? = $ac_status" >&5
     if (exit $ac_status) && test -s "$ac_outfile"; then
       # The compiler can only warn and ignore the option if not recognized
-@@ -19138,9 +19142,9 @@
+@@ -19144,9 +19148,9 @@
     -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
     -e 's:$: $lt_compiler_flag:'`
--   (eval echo "\"\$as_me:19140: $lt_compile\"" >&5)
-+   (eval echo "\"\$as_me:19144: $lt_compile\"" >&5)
+-   (eval echo "\"\$as_me:19146: $lt_compile\"" >&5)
++   (eval echo "\"\$as_me:19150: $lt_compile\"" >&5)
     (eval "$lt_compile" 2>conftest.err)
     ac_status=$?
     cat conftest.err >&5
--   echo "$as_me:19144: \$? = $ac_status" >&5
-+   echo "$as_me:19148: \$? = $ac_status" >&5
+-   echo "$as_me:19150: \$? = $ac_status" >&5
++   echo "$as_me:19154: \$? = $ac_status" >&5
     if (exit $ac_status) && test -s "$ac_outfile"; then
       # The compiler can only warn and ignore the option if not recognized
-@@ -19198,9 +19202,9 @@
+@@ -19204,9 +19208,9 @@
     -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
     -e 's:$: $lt_compiler_flag:'`
--   (eval echo "\"\$as_me:19200: $lt_compile\"" >&5)
-+   (eval echo "\"\$as_me:19204: $lt_compile\"" >&5)
+-   (eval echo "\"\$as_me:19206: $lt_compile\"" >&5)
++   (eval echo "\"\$as_me:19210: $lt_compile\"" >&5)
     (eval "$lt_compile" 2>out/conftest.err)
     ac_status=$?
     cat out/conftest.err >&5
--   echo "$as_me:19204: \$? = $ac_status" >&5
-+   echo "$as_me:19208: \$? = $ac_status" >&5
+-   echo "$as_me:19210: \$? = $ac_status" >&5
++   echo "$as_me:19214: \$? = $ac_status" >&5
     if (exit $ac_status) && test -s out/conftest2.$ac_objext
     then
-@@ -21382,5 +21386,5 @@
+@@ -21388,5 +21392,5 @@
    lt_status=$lt_dlunknown
    cat > conftest.$ac_ext <<EOF
--#line 21384 "configure"
-+#line 21388 "configure"
+-#line 21390 "configure"
++#line 21394 "configure"
  #include "confdefs.h"
  
-@@ -21480,5 +21484,5 @@
+@@ -21486,5 +21490,5 @@
    lt_status=$lt_dlunknown
    cat > conftest.$ac_ext <<EOF
--#line 21482 "configure"
-+#line 21486 "configure"
+-#line 21488 "configure"
++#line 21492 "configure"
  #include "confdefs.h"
  
-@@ -25790,4 +25794,354 @@
+@@ -25796,4 +25800,354 @@
  
  #
 +# IDN support
@@ -687,7 +687,7 @@ diff -U2 -r1.284.2.29 configure
 +#
  # Substitutions
  #
-@@ -26652,4 +27006,5 @@
+@@ -26658,4 +27012,5 @@
  s,@XMLDCL@,$XMLDCL,;t t
  s,@DOCBOOK2MANSPEC@,$DOCBOOK2MANSPEC,;t t
 +s,@IDNLIBS@,$IDNLIBS,;t t
@@ -696,11 +696,11 @@ diff -U2 -r1.284.2.29 configure
 Index: configure.in
 ===================================================================
 RCS file: /proj/cvs/prod/bind9/configure.in,v
-retrieving revision 1.294.2.32
-diff -U2 -r1.294.2.32 configure.in
---- configure.in	1 Jul 2004 00:16:42 -0000	1.294.2.32
-+++ configure.in	1 Jul 2004 03:21:58 -0000
-@@ -1769,4 +1769,80 @@
+retrieving revision 1.294.2.33
+diff -U2 -r1.294.2.33 configure.in
+--- configure.in	23 Jul 2004 04:40:32 -0000	1.294.2.33
++++ configure.in	11 Aug 2004 05:49:55 -0000
+@@ -1775,4 +1775,80 @@
  
  #
 +# IDN support
@@ -787,7 +787,7 @@ RCS file: /proj/cvs/prod/bind9/config.h.in,v
 retrieving revision 1.47.2.8
 diff -U2 -r1.47.2.8 config.h.in
 --- config.h.in	15 Mar 2004 05:00:23 -0000	1.47.2.8
-+++ config.h.in	1 Jul 2004 03:21:59 -0000
++++ config.h.in	11 Aug 2004 05:49:55 -0000
 @@ -17,5 +17,5 @@
   */
  
@@ -820,10 +820,10 @@ diff -U2 -r1.47.2.8 config.h.in
 Index: bin/dig/Makefile.in
 ===================================================================
 RCS file: /proj/cvs/prod/bind9/bin/dig/Makefile.in,v
-retrieving revision 1.25.2.2
-diff -U2 -r1.25.2.2 Makefile.in
---- bin/dig/Makefile.in	9 Mar 2004 06:09:10 -0000	1.25.2.2
-+++ bin/dig/Makefile.in	1 Jul 2004 03:21:59 -0000
+retrieving revision 1.25.2.3
+diff -U2 -r1.25.2.3 Makefile.in
+--- bin/dig/Makefile.in	20 Jul 2004 07:00:09 -0000	1.25.2.3
++++ bin/dig/Makefile.in	11 Aug 2004 05:49:56 -0000
 @@ -37,5 +37,5 @@
  DEPLIBS =	${DNSDEPLIBS} ${ISCDEPLIBS}
  
@@ -837,7 +837,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/dig.1,v
 retrieving revision 1.14.2.5
 diff -U2 -r1.14.2.5 dig.1
 --- bin/dig/dig.1	15 Mar 2004 04:44:38 -0000	1.14.2.5
-+++ bin/dig/dig.1	1 Jul 2004 03:22:01 -0000
++++ bin/dig/dig.1	11 Aug 2004 05:49:57 -0000
 @@ -355,4 +355,15 @@
  will not print the initial query when it looks up the NS records for
  isc.org.
@@ -860,7 +860,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/dig.docbook,v
 retrieving revision 1.4.2.8
 diff -U2 -r1.4.2.8 dig.docbook
 --- bin/dig/dig.docbook	9 Mar 2004 06:09:12 -0000	1.4.2.8
-+++ bin/dig/dig.docbook	1 Jul 2004 03:22:03 -0000
++++ bin/dig/dig.docbook	11 Aug 2004 05:49:58 -0000
 @@ -530,4 +530,19 @@
  
  <refsect1>
@@ -887,7 +887,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/dighost.c,v
 retrieving revision 1.221.2.22
 diff -U2 -r1.221.2.22 dighost.c
 --- bin/dig/dighost.c	15 Apr 2004 06:53:18 -0000	1.221.2.22
-+++ bin/dig/dighost.c	1 Jul 2004 03:22:16 -0000
++++ bin/dig/dighost.c	11 Aug 2004 05:50:04 -0000
 @@ -33,4 +33,15 @@
  #include <limits.h>
  
@@ -1126,7 +1126,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/host.1,v
 retrieving revision 1.11.2.2
 diff -U2 -r1.11.2.2 host.1
 --- bin/dig/host.1	15 Mar 2004 04:44:38 -0000	1.11.2.2
-+++ bin/dig/host.1	1 Jul 2004 03:22:16 -0000
++++ bin/dig/host.1	11 Aug 2004 05:50:04 -0000
 @@ -122,4 +122,15 @@
  will be set to the number of seconds given by the hardware's maximum
  value for an integer quantity.
@@ -1149,7 +1149,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/host.docbook,v
 retrieving revision 1.2.2.3
 diff -U2 -r1.2.2.3 host.docbook
 --- bin/dig/host.docbook	9 Mar 2004 06:09:13 -0000	1.2.2.3
-+++ bin/dig/host.docbook	1 Jul 2004 03:22:21 -0000
++++ bin/dig/host.docbook	11 Aug 2004 05:50:05 -0000
 @@ -182,4 +182,19 @@
  
  <refsect1>
@@ -1176,7 +1176,7 @@ RCS file: /proj/cvs/prod/bind9/lib/dns/name.c,v
 retrieving revision 1.127.2.9
 diff -U2 -r1.127.2.9 name.c
 --- lib/dns/name.c	9 Mar 2004 06:11:03 -0000	1.127.2.9
-+++ lib/dns/name.c	1 Jul 2004 03:22:35 -0000
++++ lib/dns/name.c	11 Aug 2004 05:50:10 -0000
 @@ -196,4 +196,11 @@
  dns_name_t *dns_wildcardname = &wild;
  
@@ -1218,10 +1218,10 @@ diff -U2 -r1.127.2.9 name.c
 Index: lib/dns/include/dns/name.h
 ===================================================================
 RCS file: /proj/cvs/prod/bind9/lib/dns/include/dns/name.h,v
-retrieving revision 1.95.2.5
-diff -U2 -r1.95.2.5 name.h
---- lib/dns/include/dns/name.h	9 Mar 2004 06:11:19 -0000	1.95.2.5
-+++ lib/dns/include/dns/name.h	1 Jul 2004 03:22:37 -0000
+retrieving revision 1.95.2.7
+diff -U2 -r1.95.2.7 name.h
+--- lib/dns/include/dns/name.h	10 Aug 2004 00:41:49 -0000	1.95.2.7
++++ lib/dns/include/dns/name.h	11 Aug 2004 05:50:13 -0000
 @@ -220,4 +220,15 @@
  #define DNS_NAME_MAXWIRE 255
  
@@ -1238,7 +1238,7 @@ diff -U2 -r1.95.2.5 name.h
 +
  /***
   *** Initialization
-@@ -1261,4 +1272,12 @@
+@@ -1264,4 +1275,12 @@
   *
   */
 +
diff --git a/contrib/nslint-2.1a3/Makefile.in b/contrib/nslint-2.1a3/Makefile.in
index 5f21cc4f..ea2ca422 100644
--- a/contrib/nslint-2.1a3/Makefile.in
+++ b/contrib/nslint-2.1a3/Makefile.in
@@ -17,7 +17,7 @@
 #  WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
 #  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 #
-# @(#) $Id: Makefile.in,v 1.1 2001/12/21 04:12:02 marka Exp $ (LBL)
+# @(#) $Id: Makefile.in,v 1.1.2.1 2004/07/20 07:00:18 marka Exp $ (LBL)
 
 #
 # Various configurable paths (remember to edit Makefile.in, not Makefile)
@@ -79,7 +79,7 @@ CLEANFILES = $(PROG) $(OBJ) $(GENSRC)
 
 $(PROG): $(OBJ)
 	@rm -f $@
-	$(CC) $(CFLAGS) -o $@ $(OBJ) $(LIBS)
+	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJ) $(LIBS)
 
 version.o: version.c
 version.c: $(srcdir)/VERSION
diff --git a/contrib/queryperf/Makefile.in b/contrib/queryperf/Makefile.in
index 2ed19a47..b6804a75 100644
--- a/contrib/queryperf/Makefile.in
+++ b/contrib/queryperf/Makefile.in
@@ -5,7 +5,7 @@ LIBS = @LIBS@
 DEFS = @DEFS@
 
 queryperf: queryperf.o
-	$(CC) $(CFLAGS) $(DEFS) queryperf.o $(LIBS) -lm -o queryperf
+	$(CC) $(CFLAGS) $(DEFS) $(LDFLAGS) queryperf.o $(LIBS) -lm -o queryperf
 
 queryperf.o: queryperf.c
 	$(CC) $(CFLAGS) $(DEFS) -c queryperf.c
diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt
deleted file mode 100644
index 4634cfdf..00000000
--- a/doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-DNSEXT Working Group                                            M. Stapp
-Internet-Draft                                       Cisco Systems, Inc.
-Expires: April 23, 2004                                         T. Lemon
-                                                           A. Gustafsson
-                                                           Nominum, Inc.
-                                                        October 24, 2003
-
-
-           A DNS RR for Encoding DHCP Information (DHCID RR)
-                  <draft-ietf-dnsext-dhcid-rr-07.txt>
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or obsoleted by other documents
-   at any time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 23, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
-   It is possible for multiple DHCP clients to attempt to update the
-   same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
-   the clients themselves perform the DNS updates, conflicts can arise.
-   To resolve such conflicts, "Resolution of DNS Name Conflicts"[1]
-   proposes storing client identifiers in the DNS to unambiguously
-   associate domain names with the DHCP clients to which they refer.
-   This memo defines a distinct RR type for this purpose for use by
-   DHCP clients and servers, the "DHCID" RR.
-
-
-
-
-Stapp, et. al.           Expires April 23, 2004                 [Page 1]
-
-Internet-Draft                The DHCID RR                  October 2003
-
-
-Table of Contents
-
-   1.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.    The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.1   DHCID RDATA format . . . . . . . . . . . . . . . . . . . . .  4
-   3.2   DHCID Presentation Format  . . . . . . . . . . . . . . . . .  4
-   3.3   The DHCID RR Type Codes  . . . . . . . . . . . . . . . . . .  4
-   3.4   Computation of the RDATA . . . . . . . . . . . . . . . . . .  5
-   3.5   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   3.5.1 Example 1  . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   3.5.2 Example 2  . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   4.    Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . .  6
-   5.    Updater Behavior . . . . . . . . . . . . . . . . . . . . . .  6
-   6.    Security Considerations  . . . . . . . . . . . . . . . . . .  7
-   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  7
-   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  7
-         References . . . . . . . . . . . . . . . . . . . . . . . . .  7
-         References . . . . . . . . . . . . . . . . . . . . . . . . .  8
-         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  8
-         Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et. al.           Expires April 23, 2004                 [Page 2]
-
-Internet-Draft                The DHCID RR                  October 2003
-
-
-1. Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119[2].
-
-2. Introduction
-
-   A set of procedures to allow DHCP[7] clients and servers to
-   automatically update the DNS (RFC 1034[3], RFC 1035[4]) is proposed
-   in "Resolution of DNS Name Conflicts"[1].
-
-   Conflicts can arise if multiple DHCP clients wish to use the same
-   DNS name. To resolve such conflicts, "Resolution of DNS Name
-   Conflicts"[1] proposes storing client identifiers in the DNS to
-   unambiguously associate domain names with the DHCP clients using
-   them. In the interest of clarity, it is preferable for this DHCP
-   information to use a distinct RR type. This memo defines a distinct
-   RR for this purpose for use by DHCP clients or servers, the "DHCID"
-   RR.
-
-   In order to avoid exposing potentially sensitive identifying
-   information, the data stored is the result of a one-way MD5[5] hash
-   computation. The hash includes information from the DHCP client's
-   REQUEST message as well as the domain name itself, so that the data
-   stored in the DHCID RR will be dependent on both the client
-   identification used in the DHCP protocol interaction and the domain
-   name. This means that the DHCID RDATA will vary if a single client
-   is associated over time with more than one name. This makes it
-   difficult to 'track' a client as it is associated with various
-   domain names.
-
-   The MD5 hash algorithm has been shown to be weaker than the SHA-1
-   algorithm; it could therefore be argued that SHA-1 is a better
-   choice. However, SHA-1 is significantly slower than MD5. A
-   successful attack of MD5's weakness does not reveal the original
-   data that was used to generate the signature, but rather provides a
-   new set of input data that will produce the same signature. Because
-   we are using the MD5 hash to conceal the original data, the fact
-   that an attacker could produce a different plaintext resulting in
-   the same MD5 output is not significant concern.
-
-3. The DHCID RR
-
-   The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
-   DHCID RR is only defined in the IN class. DHCID RRs cause no
-   additional section processing. The DHCID RR is not a singleton type.
-
-
-
-
-Stapp, et. al.           Expires April 23, 2004                 [Page 3]
-
-Internet-Draft                The DHCID RR                  October 2003
-
-
-3.1 DHCID RDATA format
-
-   The RDATA section of a DHCID RR in transmission contains RDLENGTH
-   bytes of binary data.  The format of this data and its
-   interpretation by DHCP servers and clients are described below.
-
-   DNS software should consider the RDATA section to be opaque. DHCP
-   clients or servers use the DHCID RR to associate a DHCP client's
-   identity with a DNS name, so that multiple DHCP clients and servers
-   may deterministically perform dynamic DNS updates to the same zone.
-   From the updater's perspective, the DHCID resource record RDATA
-   consists of a 16-bit identifier type, in network byte order,
-   followed by one or more bytes representing the actual identifier:
-
-     	< 16 bits >	DHCP identifier used
-     	< n bytes >	MD5 digest
-
-3.2 DHCID Presentation Format
-
-   In DNS master files, the RDATA is represented as a single block in
-   base 64 encoding identical to that used for representing binary data
-   in RFC 2535[8]. The data may be divided up into any number of white
-   space separated substrings, down to single base 64 digits, which are
-   concatenated to form the complete RDATA.  These substrings can span
-   lines using the standard parentheses.
-
-3.3 The DHCID RR Type Codes
-
-   The DHCID RR Type Code specifies what data from the DHCP client's
-   request was used as input into the hash function. The type codes are
-   defined in a registry maintained by IANA, as specified in Section 7.
-   The initial list of assigned values for the type code is:
-
-     0x0000 = htype, chaddr from a DHCPv4 client's
-              DHCPREQUEST (RFC 2131)
-     0x0001 = The data portion from a DHCPv4 client's Client
-              Identifier option (RFC 2132)
-     0x0002 = The data portion (i.e., the DUID) from a DHCPv6
-              client's Client Identifier option
-   	   (draft-ietf-dhc-dhcpv6-*.txt)
-
-     0x0003 - 0xfffe = Available to be assigned by IANA
-
-     0xffff = RESERVED
-
-
-
-
-
-
-
-Stapp, et. al.           Expires April 23, 2004                 [Page 4]
-
-Internet-Draft                The DHCID RR                  October 2003
-
-
-3.4 Computation of the RDATA
-
-   The DHCID RDATA is formed by concatenating the two type bytes with
-   some variable-length identifying data.
-
-       < type > < data >
-
-   The RDATA for all type codes other than 0xffff, which is reserved
-   for future expansion, is formed by concatenating the two type bytes
-   and a 16-byte MD5 hash value. The input to the hash function is
-   defined to be:
-
-       data = MD5(< identifier > < FQDN >)
-
-   The FQDN is represented in the buffer in unambiguous canonical form
-   as described in RFC 2535[8], section 8.1. The type code and the
-   identifier are related as specified in Section 3.3: the type code
-   describes the source of the identifier.
-
-   When the updater is using the client's link-layer address as the
-   identifier, the first two bytes of the DHCID RDATA MUST be zero. To
-   generate the rest of the resource record, the updater computes a
-   one-way hash using the MD5 algorithm across a buffer containing the
-   client's network hardware type, link-layer address, and the FQDN
-   data.  Specifically, the first byte of the buffer contains the
-   network hardware type as it appeared in the DHCP 'htype' field of
-   the client's DHCPREQUEST message. All of the significant bytes of
-   the chaddr field in the client's DHCPREQUEST message follow, in the
-   same order in which the bytes appear in the DHCPREQUEST message. The
-   number of significant bytes in the 'chaddr' field is specified in
-   the 'hlen' field of the DHCPREQUEST message. The FQDN data, as
-   specified above, follows.
-
-   When the updater is using the DHCPv4 Client Identifier option sent
-   by the client in its DHCPREQUEST message, the first two bytes of the
-   DHCID RR MUST be 0x0001, in network byte order. The rest of the
-   DHCID RR MUST contain the results of computing an MD5 hash across
-   the payload of the option, followed by the FQDN. The payload of the
-   option consists of the bytes of the option following the option code
-   and length.
-
-   When the updater is using the DHCPv6 DUID sent by the client in its
-   REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
-   in network byte order. The rest of the DHCID RR MUST contain the
-   results of computing an MD5 hash across the payload of the option,
-   followed by the FQDN. The payload of the option consists of the
-   bytes of the option following the option code and length.
-
-
-
-
-Stapp, et. al.           Expires April 23, 2004                 [Page 5]
-
-Internet-Draft                The DHCID RR                  October 2003
-
-
-3.5 Examples
-
-3.5.1 Example 1
-
-   A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
-   Ethernet MAC address 01:02:03:04:05:06 using domain name
-   "client.example.com" uses the client's link-layer address to
-   identify the client. The DHCID RDATA is composed by setting the two
-   type bytes to zero, and performing an MD5 hash computation across a
-   buffer containing the Ethernet MAC type byte, 0x01, the six bytes of
-   MAC address, and the domain name (represented as specified in
-   Section 3.4).
-
-     client.example.com.	A   	10.0.0.1
-     client.example.com. 	DHCID 	AAAUMru0ZM5OK/PdVAJgZ/HU
-
-3.5.2 Example 2
-
-   A DHCP server allocates the IPv4 address 10.0.12.99 to a client
-   which included the DHCP client-identifier option data
-   01:07:08:09:0a:0b:0c in its DHCP request. The server updates the
-   name "chi.example.com" on the client's behalf, and uses the DHCP
-   client identifier option data as input in forming a DHCID RR. The
-   DHCID RDATA is formed by setting the two type bytes to the value
-   0x0001, and performing an MD5 hash computation across a buffer
-   containing the seven bytes from the client-id option and the FQDN
-   (represented as specified in Section 3.4).
-
-     chi.example.com.	A    	10.0.12.99
-     chi.example.com.	DHCID 	AAHdd5jiQ3kEjANDm82cbObk\012
-
-4. Use of the DHCID RR
-
-   This RR MUST NOT be used for any purpose other than that detailed in
-   "Resolution of DNS Name Conflicts"[1]. Although this RR contains
-   data that is opaque to DNS servers, the data must be consistent
-   across all entities that update and interpret this record.
-   Therefore, new data formats may only be defined through actions of
-   the DHC Working Group, as a result of revising [1].
-
-5. Updater Behavior
-
-   The data in the DHCID RR allows updaters to determine whether more
-   than one DHCP client desires to use a particular FQDN.  This allows
-   site administrators to establish policy about DNS updates. The DHCID
-   RR does not establish any policy itself.
-
-   Updaters use data from a DHCP client's request and the domain name
-   that the client desires to use to compute a client identity hash,
-
-
-Stapp, et. al.           Expires April 23, 2004                 [Page 6]
-
-Internet-Draft                The DHCID RR                  October 2003
-
-
-   and then compare that hash to the data in any DHCID RRs on the name
-   that they wish to associate with the client's IP address. If an
-   updater discovers DHCID RRs whose RDATA does not match the client
-   identity that they have computed, the updater SHOULD conclude that a
-   different client is currently associated with the name in question.
-   The updater SHOULD then proceed according to the site's
-   administrative policy. That policy might dictate that a different
-   name be selected, or it might permit the updater to continue.
-
-6. Security Considerations
-
-   The DHCID record as such does not introduce any new security
-   problems into the DNS.  In order to avoid exposing private
-   information about DHCP clients to public scrutiny, a one-way hash is
-   used to obscure all client information. In order to make it
-   difficult to 'track' a client by examining the names associated with
-   a particular hash value, the FQDN is included in the hash
-   computation. Thus, the RDATA is dependent on both the DHCP client
-   identification data and on each FQDN associated with the client.
-
-   Administrators should be wary of permitting unsecured DNS updates to
-   zones which are exposed to the global Internet. Both DHCP clients
-   and servers SHOULD use some form of update authentication (e.g.,
-   TSIG[11]) when performing DNS updates.
-
-7. IANA Considerations
-
-   IANA is requested to allocate an RR type number for the DHCID record
-   type.
-
-   This specification defines a new number-space for the 16-bit type
-   codes associated with the DHCID RR. IANA is requested to establish a
-   registry of the values for this number-space.
-
-   Three initial values are assigned in Section 3.3, and the value
-   0xFFFF is reserved for future use. New DHCID RR type codes are
-   tentatively assigned after the specification for the associated type
-   code, published as an Internet Draft, has received expert review by
-   a designated expert. The final assignment of DHCID RR type codes is
-   through Standards Action, as defined in RFC 2434[6].
-
-8. Acknowledgements
-
-   Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz,
-   and Ralph Droms for their review and suggestions.
-
-Normative References
-
-   [1]  Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients
-
-
-Stapp, et. al.           Expires April 23, 2004                 [Page 7]
-
-Internet-Draft                The DHCID RR                  October 2003
-
-
-        (draft-ietf-dhc-dns-resolution-*)", November 2002.
-
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", RFC 2119, March 1997.
-
-   [3]  Mockapetris, P., "Domain names - Concepts and Facilities", RFC
-        1034, Nov 1987.
-
-   [4]  Mockapetris, P., "Domain names - Implementation and
-        Specification", RFC 1035, Nov 1987.
-
-   [5]  Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April
-        1992.
-
-   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", RFC 2434, October 1998.
-
-Informative References
-
-   [7]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-         Mar 1997.
-
-   [8]   Eastlake, D., "Domain Name System Security Extensions", RFC
-         2535, March 1999.
-
-   [9]   Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
-         Extensions", RFC 2132, Mar 1997.
-
-   [10]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
-         Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
-         (draft-ietf-dhc-dhcpv6-*.txt)", November 2002.
-
-   [11]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-         2845, May 2000.
-
-
-Authors' Addresses
-
-   Mark Stapp
-   Cisco Systems, Inc.
-   1414 Massachusetts Ave.
-   Boxborough, MA  01719
-   USA
-
-   Phone: 978.936.1535
-   EMail: mjs@cisco.com
-
-
-
-
-Stapp, et. al.           Expires April 23, 2004                 [Page 8]
-
-Internet-Draft                The DHCID RR                  October 2003
-
-
-   Ted Lemon
-   Nominum, Inc.
-   950 Charter St.
-   Redwood City, CA  94063
-   USA
-
-   EMail: mellon@nominum.com
-
-
-   Andreas Gustafsson
-   Nominum, Inc.
-   950 Charter St.
-   Redwood City, CA  94063
-   USA
-
-   EMail: gson@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et. al.           Expires April 23, 2004                 [Page 9]
-
-Internet-Draft                The DHCID RR                  October 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph
-   are included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et. al.           Expires April 23, 2004                [Page 10]
-
diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
new file mode 100644
index 00000000..09776618
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
@@ -0,0 +1,561 @@
+
+
+DNSEXT                                                          M. Stapp
+Internet-Draft                                       Cisco Systems, Inc.
+Expires: January 14, 2005                                       T. Lemon
+                                                           A. Gustafsson
+                                                           Nominum, Inc.
+                                                           July 16, 2004
+
+
+           A DNS RR for Encoding DHCP Information (DHCID RR)
+                  <draft-ietf-dnsext-dhcid-rr-08.txt>
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 14, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   It is possible for multiple DHCP clients to attempt to update the
+   same DNS FQDN as they obtain DHCP leases.  Whether the DHCP server or
+   the clients themselves perform the DNS updates, conflicts can arise.
+   To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
+   proposes storing client identifiers in the DNS to unambiguously
+
+
+
+Stapp, et al.           Expires January 14, 2005                [Page 1]
+
+Internet-Draft                The DHCID RR                     July 2004
+
+
+   associate domain names with the DHCP clients to which they refer.
+   This memo defines a distinct RR type for this purpose for use by DHCP
+   clients and servers, the "DHCID" RR.
+
+Table of Contents
+
+   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.1   DHCID RDATA format . . . . . . . . . . . . . . . . . . . .  4
+     3.2   DHCID Presentation Format  . . . . . . . . . . . . . . . .  4
+     3.3   The DHCID RR Type Codes  . . . . . . . . . . . . . . . . .  4
+     3.4   Computation of the RDATA . . . . . . . . . . . . . . . . .  4
+     3.5   Examples . . . . . . . . . . . . . . . . . . . . . . . . .  5
+       3.5.1   Example 1  . . . . . . . . . . . . . . . . . . . . . .  6
+       3.5.2   Example 2  . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Updater Behavior . . . . . . . . . . . . . . . . . . . . . . .  6
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   9.1   Normative References . . . . . . . . . . . . . . . . . . . .  8
+   9.2   Informative References . . . . . . . . . . . . . . . . . . .  8
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
+       Intellectual Property and Copyright Statements . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al.           Expires January 14, 2005                [Page 2]
+
+Internet-Draft                The DHCID RR                     July 2004
+
+
+1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+2.  Introduction
+
+   A set of procedures to allow DHCP [7] clients and servers to
+   automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
+   in "Resolution of DNS Name Conflicts" [1].
+
+   Conflicts can arise if multiple DHCP clients wish to use the same DNS
+   name.  To resolve such conflicts, "Resolution of DNS Name Conflicts"
+   [1] proposes storing client identifiers in the DNS to unambiguously
+   associate domain names with the DHCP clients using them.  In the
+   interest of clarity, it is preferable for this DHCP information to
+   use a distinct RR type.  This memo defines a distinct RR for this
+   purpose for use by DHCP clients or servers, the "DHCID" RR.
+
+   In order to avoid exposing potentially sensitive identifying
+   information, the data stored is the result of a one-way MD5 [5] hash
+   computation.  The hash includes information from the DHCP client's
+   REQUEST message as well as the domain name itself, so that the data
+   stored in the DHCID RR will be dependent on both the client
+   identification used in the DHCP protocol interaction and the domain
+   name.  This means that the DHCID RDATA will vary if a single client
+   is associated over time with more than one name.  This makes it
+   difficult to 'track' a client as it is associated with various domain
+   names.
+
+   The MD5 hash algorithm has been shown to be weaker than the SHA-1
+   algorithm; it could therefore be argued that SHA-1 is a better
+   choice.  However, SHA-1 is significantly slower than MD5.  A
+   successful attack of MD5's weakness does not reveal the original data
+   that was used to generate the signature, but rather provides a new
+   set of input data that will produce the same signature.  Because we
+   are using the MD5 hash to conceal the original data, the fact that an
+   attacker could produce a different plaintext resulting in the same
+   MD5 output is not significant concern.
+
+3.  The DHCID RR
+
+   The DHCID RR is defined with mnemonic DHCID and type code [TBD].  The
+   DHCID RR is only defined in the IN class.  DHCID RRs cause no
+   additional section processing.  The DHCID RR is not a singleton type.
+
+
+
+
+
+Stapp, et al.           Expires January 14, 2005                [Page 3]
+
+Internet-Draft                The DHCID RR                     July 2004
+
+
+3.1  DHCID RDATA format
+
+   The RDATA section of a DHCID RR in transmission contains RDLENGTH
+   bytes of binary data.  The format of this data and its interpretation
+   by DHCP servers and clients are described below.
+
+   DNS software should consider the RDATA section to be opaque.  DHCP
+   clients or servers use the DHCID RR to associate a DHCP client's
+   identity with a DNS name, so that multiple DHCP clients and servers
+   may deterministically perform dynamic DNS updates to the same zone.
+   From the updater's perspective, the DHCID resource record RDATA
+   consists of a 16-bit identifier type, in network byte order, followed
+   by one or more bytes representing the actual identifier:
+
+     	< 16 bits >	DHCP identifier used
+     	< n bytes >	MD5 digest
+
+
+3.2  DHCID Presentation Format
+
+   In DNS master files, the RDATA is represented as a single block in
+   base 64 encoding identical to that used for representing binary data
+   in RFC 2535 [8].  The data may be divided up into any number of white
+   space separated substrings, down to single base 64 digits, which are
+   concatenated to form the complete RDATA.  These substrings can span
+   lines using the standard parentheses.
+
+3.3  The DHCID RR Type Codes
+
+   The DHCID RR Type Code specifies what data from the DHCP client's
+   request was used as input into the hash function.  The type codes are
+   defined in a registry maintained by IANA, as specified in Section 7.
+   The initial list of assigned values for the type code is:
+
+   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
+   0x0001 = The data portion from a DHCPv4 client's Client Identifier
+      option [9].
+   0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
+      client's Client Identifier option [10] or the DUID field from a
+      DHCPv4 client's Client Identifier option [12]).
+
+   0x0003 - 0xfffe = Available to be assigned by IANA.
+
+   0xffff = RESERVED
+
+3.4  Computation of the RDATA
+
+   The DHCID RDATA is formed by concatenating the two type bytes with
+
+
+
+Stapp, et al.           Expires January 14, 2005                [Page 4]
+
+Internet-Draft                The DHCID RR                     July 2004
+
+
+   some variable-length identifying data.
+
+       < type > < data >
+
+   The RDATA for all type codes other than 0xffff, which is reserved for
+   future expansion, is formed by concatenating the two type bytes and a
+   16-byte MD5 hash value.  The input to the hash function is defined to
+   be:
+
+       data = MD5(< identifier > < FQDN >)
+
+   The FQDN is represented in the buffer in unambiguous canonical form
+   as described in RFC 2535 [8], section 8.1.  The type code and the
+   identifier are related as specified in Section 3.3: the type code
+   describes the source of the identifier.
+
+   When the updater is using the client's link-layer address as the
+   identifier, the first two bytes of the DHCID RDATA MUST be zero.  To
+   generate the rest of the resource record, the updater computes a
+   one-way hash using the MD5 algorithm across a buffer containing the
+   client's network hardware type, link-layer address, and the FQDN
+   data.  Specifically, the first byte of the buffer contains the
+   network hardware type as it appeared in the DHCP 'htype' field of the
+   client's DHCPREQUEST message.  All of the significant bytes of the
+   chaddr field in the client's DHCPREQUEST message follow, in the same
+   order in which the bytes appear in the DHCPREQUEST message.  The
+   number of significant bytes in the 'chaddr' field is specified in the
+   'hlen' field of the DHCPREQUEST message.  The FQDN data, as specified
+   above, follows.
+
+   When the updater is using the DHCPv4 Client Identifier option sent by
+   the client in its DHCPREQUEST message, the first two bytes of the
+   DHCID RR MUST be 0x0001, in network byte order.  The rest of the
+   DHCID RR MUST contain the results of computing an MD5 hash across the
+   payload of the option, followed by the FQDN.  The payload of the
+   option consists of the bytes of the option following the option code
+   and length.
+
+   When the updater is using the DHCPv6 DUID sent by the client in its
+   REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
+   in network byte order.  The rest of the DHCID RR MUST contain the
+   results of computing an MD5 hash across the payload of the option,
+   followed by the FQDN.  The payload of the option consists of the
+   bytes of the option following the option code and length.
+
+3.5  Examples
+
+
+
+
+
+Stapp, et al.           Expires January 14, 2005                [Page 5]
+
+Internet-Draft                The DHCID RR                     July 2004
+
+
+3.5.1  Example 1
+
+   A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
+   Ethernet MAC address 01:02:03:04:05:06 using domain name
+   "client.example.com" uses the client's link-layer address to identify
+   the client.  The DHCID RDATA is composed by setting the two type
+   bytes to zero, and performing an MD5 hash computation across a buffer
+   containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
+   address, and the domain name (represented as specified in Section
+   3.4).
+
+     client.example.com.	A   	10.0.0.1
+     client.example.com. 	DHCID 	AAAUMru0ZM5OK/PdVAJgZ/HU
+
+
+3.5.2  Example 2
+
+   A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
+   included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
+   in its DHCP request.  The server updates the name "chi.example.com"
+   on the client's behalf, and uses the DHCP client identifier option
+   data as input in forming a DHCID RR.  The DHCID RDATA is formed by
+   setting the two type bytes to the value 0x0001, and performing an MD5
+   hash computation across a buffer containing the seven bytes from the
+   client-id option and the FQDN (represented as specified in Section
+   3.4).
+
+     chi.example.com.	A    	10.0.12.99
+     chi.example.com.	DHCID 	AAHdd5jiQ3kEjANDm82cbObk\012
+
+
+4.  Use of the DHCID RR
+
+   This RR MUST NOT be used for any purpose other than that detailed in
+   "Resolution of DNS Name Conflicts" [1].  Although this RR contains
+   data that is opaque to DNS servers, the data must be consistent
+   across all entities that update and interpret this record.
+   Therefore, new data formats may only be defined through actions of
+   the DHC Working Group, as a result of revising [1].
+
+5.  Updater Behavior
+
+   The data in the DHCID RR allows updaters to determine whether more
+   than one DHCP client desires to use a particular FQDN.  This allows
+   site administrators to establish policy about DNS updates.  The DHCID
+   RR does not establish any policy itself.
+
+   Updaters use data from a DHCP client's request and the domain name
+
+
+
+Stapp, et al.           Expires January 14, 2005                [Page 6]
+
+Internet-Draft                The DHCID RR                     July 2004
+
+
+   that the client desires to use to compute a client identity hash, and
+   then compare that hash to the data in any DHCID RRs on the name that
+   they wish to associate with the client's IP address.  If an updater
+   discovers DHCID RRs whose RDATA does not match the client identity
+   that they have computed, the updater SHOULD conclude that a different
+   client is currently associated with the name in question.  The
+   updater SHOULD then proceed according to the site's administrative
+   policy.  That policy might dictate that a different name be selected,
+   or it might permit the updater to continue.
+
+6.  Security Considerations
+
+   The DHCID record as such does not introduce any new security problems
+   into the DNS.  In order to avoid exposing private information about
+   DHCP clients to public scrutiny, a one-way hash is used to obscure
+   all client information.  In order to make it difficult to 'track' a
+   client by examining the names associated with a particular hash
+   value, the FQDN is included in the hash computation.  Thus, the RDATA
+   is dependent on both the DHCP client identification data and on each
+   FQDN associated with the client.
+
+   Administrators should be wary of permitting unsecured DNS updates to
+   zones which are exposed to the global Internet.  Both DHCP clients
+   and servers SHOULD use some form of update authentication (e.g., TSIG
+   [11]) when performing DNS updates.
+
+7.  IANA Considerations
+
+   IANA is requested to allocate an RR type number for the DHCID record
+   type.
+
+   This specification defines a new number-space for the 16-bit type
+   codes associated with the DHCID RR.  IANA is requested to establish a
+   registry of the values for this number-space.
+
+   Three initial values are assigned in Section 3.3, and the value
+   0xFFFF is reserved for future use.  New DHCID RR type codes are
+   tentatively assigned after the specification for the associated type
+   code, published as an Internet Draft, has received expert review by a
+   designated expert.  The final assignment of DHCID RR type codes is
+   through Standards Action, as defined in RFC 2434 [6].
+
+8.  Acknowledgements
+
+   Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and
+   Ralph Droms for their review and suggestions.
+
+
+
+
+
+Stapp, et al.           Expires January 14, 2005                [Page 7]
+
+Internet-Draft                The DHCID RR                     July 2004
+
+
+9.  References
+
+9.1  Normative References
+
+   [1]  Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
+        DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [4]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [5]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+        1992.
+
+   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+9.2  Informative References
+
+   [7]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+         March 1997.
+
+   [8]   Eastlake, D., "Domain Name System Security Extensions", RFC
+         2535, March 1999.
+
+   [9]   Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+         Extensions", RFC 2132, March 1997.
+
+   [10]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
+         Carney, "Dynamic Host Configuration Protocol for IPv6
+         (DHCPv6)", RFC 3315, July 2003.
+
+   [11]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+         2845, May 2000.
+
+   [12]  Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
+         for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
+
+
+
+
+
+
+
+
+Stapp, et al.           Expires January 14, 2005                [Page 8]
+
+Internet-Draft                The DHCID RR                     July 2004
+
+
+Authors' Addresses
+
+   Mark Stapp
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxborough, MA  01719
+   USA
+
+   Phone: 978.936.1535
+   EMail: mjs@cisco.com
+
+
+   Ted Lemon
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   USA
+
+   EMail: mellon@nominum.com
+
+
+   Andreas Gustafsson
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   USA
+
+   EMail: gson@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al.           Expires January 14, 2005                [Page 9]
+
+Internet-Draft                The DHCID RR                     July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Stapp, et al.           Expires January 14, 2005               [Page 10]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
index 5ac9cba5..0783e7b2 100644
--- a/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt
+++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
@@ -1,1513 +1,1457 @@
-

-

-DNS Extensions                                                 R. Arends

-Internet-Draft                                      Telematica Instituut

-Expires: November 15, 2004                                    R. Austein

-                                                                     ISC

-                                                               M. Larson

-                                                                VeriSign

-                                                               D. Massey

-                                                                 USC/ISI

-                                                                 S. Rose

-                                                                    NIST

-                                                            May 17, 2004

-

-

-               DNS Security Introduction and Requirements

-                   draft-ietf-dnsext-dnssec-intro-10

-

-Status of this Memo

-

-   This document is an Internet-Draft and is in full conformance with

-   all provisions of Section 10 of RFC2026.

-

-   Internet-Drafts are working documents of the Internet Engineering

-   Task Force (IETF), its areas, and its working groups. Note that other

-   groups may also distribute working documents as Internet-Drafts.

-

-   Internet-Drafts are draft documents valid for a maximum of six months

-   and may be updated, replaced, or obsoleted by other documents at any

-   time. It is inappropriate to use Internet-Drafts as reference

-   material or to cite them other than as "work in progress."

-

-   The list of current Internet-Drafts can be accessed at http://

-   www.ietf.org/ietf/1id-abstracts.txt.

-

-   The list of Internet-Draft Shadow Directories can be accessed at

-   http://www.ietf.org/shadow.html.

-

-   This Internet-Draft will expire on November 15, 2004.

-

-Copyright Notice

-

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

-

-Abstract

-

-   The Domain Name System Security Extensions (DNSSEC) add data origin

-   authentication and data integrity to the Domain Name System.  This

-   document introduces these extensions, and describes their

-   capabilities and limitations.  This document also discusses the

-   services that the DNS security extensions do and do not provide.

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 1]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-   Last, this document describes the interrelationships between the

-   group of documents that collectively describe DNSSEC.

-

-Table of Contents

-

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

-   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . . .  4

-   3.  Services Provided by DNS Security  . . . . . . . . . . . . . .  8

-     3.1   Data Origin Authentication and Data Integrity  . . . . . .  8

-     3.2   Authenticating Name and Type Non-Existence . . . . . . . .  9

-   4.  Services Not Provided by DNS Security  . . . . . . . . . . . . 11

-   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12

-   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . . . 14

-   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15

-   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . . . 16

-     8.1   TTL values vs. RRSIG validity period . . . . . . . . . . . 16

-     8.2   New Temporal Dependency Issues for Zones . . . . . . . . . 16

-   9.  Name Server Considerations . . . . . . . . . . . . . . . . . . 17

-   10.   DNS Security Document Family . . . . . . . . . . . . . . . . 18

-   11.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 19

-   12.   Security Considerations  . . . . . . . . . . . . . . . . . . 20

-   13.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22

-   14.   References . . . . . . . . . . . . . . . . . . . . . . . . . 23

-   14.1  Normative References . . . . . . . . . . . . . . . . . . . . 23

-   14.2  Informative References . . . . . . . . . . . . . . . . . . . 23

-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25

-       Intellectual Property and Copyright Statements . . . . . . . . 26

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 2]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-1.  Introduction

-

-   This document introduces the Domain Name System Security Extensions

-   (DNSSEC).  This document and its two companion documents

-   ([I-D.ietf-dnsext-dnssec-records] and

-   [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the

-   security extensions defined in RFC 2535 [RFC2535] and its

-   predecessors. These security extensions consist of a set of new

-   resource record types and modifications to the existing DNS protocol

-   [RFC1035].  The new records and protocol modifications are not fully

-   described in this document, but are described in a family of

-   documents outlined in Section 10. Section 3 and Section 4 describe

-   the capabilities and limitations of the security extensions in

-   greater detail.  Section 5 discusses the scope of the document set.

-   Section 6, Section 7, Section 8, and Section 9 discuss the effect

-   that these security extensions will have on resolvers, stub

-   resolvers, zones and name servers.

-

-   This document and its two companions update and obsolete RFCs 2535

-   [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655

-   [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress

-   [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but

-   does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136

-   [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts

-   of 3226 [RFC3226] (dealing with DNSSEC).

-

-   The DNS security extensions provide origin authentication and

-   integrity protection for DNS data, as well as a means of public key

-   distribution.  These extensions do not provide confidentiality.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 3]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-2.  Definitions of Important DNSSEC Terms

-

-   This section defines a number of terms used in this document set.

-   Since this is intended to be useful as a reference while reading the

-   rest of the document set, first-time readers may wish to skim this

-   section quickly, read the rest of this document, then come back to

-   this section.

-

-   Authentication Chain: An alternating sequence of DNSKEY RRsets and DS

-      RRsets forms a chain of signed data, with each link in the chain

-      vouching for the next.  A DNSKEY RR is used to verify the

-      signature covering a DS RR and allows the DS RR to be

-      authenticated.  The DS RR contains a hash of another DNSKEY RR and

-      this new DNSKEY RR is authenticated by matching the hash in the DS

-      RR.  This new DNSKEY RR in turn authenticates another DNSKEY RRset

-      and, in turn, some DNSKEY RR in this set may be used to

-      authenticate another DS RR and so forth until the chain finally

-      ends with a DNSKEY RR whose corresponding private key signs the

-      desired DNS data.  For example, the root DNSKEY RRset can be used

-      to authenticate the DS RRset for "example."  The "example." DS

-      RRset contains a hash that matches some "example." DNSKEY, and

-      this DNSKEY's corresponding private key signs the "example."

-      DNSKEY RRset.  Private key counterparts of the "example." DNSKEY

-      RRset sign data records such as "www.example." as well as DS RRs

-      for delegations such as "subzone.example."

-

-   Authentication Key: A public key that a security-aware resolver has

-      verified and can therefore use to authenticate data.  A

-      security-aware resolver can obtain authentication keys in three

-      ways.  First, the resolver is generally configured to know about

-      at least one public key; this configured data is usually either

-      the public key itself or a hash of the public key as found in the

-      DS RR (see "trust anchor").  Second, the resolver may use an

-      authenticated public key to verify a DS RR and its associated

-      DNSKEY RR.  Third, the resolver may be able to determine that a

-      new public key has been signed by the private key corresponding to

-      another public key which the resolver has verified.  Note that the

-      resolver must always be guided by local policy when deciding

-      whether to authenticate a new public key, even if the local policy

-      is simply to authenticate any new public key for which the

-      resolver is able verify the signature.

-

-   Delegation Point: Term used to describe the name at the parental side

-      of a zone cut.  That is, the delegation point for "foo.example"

-      would be the foo.example node in the "example" zone (as opposed to

-      the zone apex of the "foo.example" zone).

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 4]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-   Island of Security: Term used to describe a signed, delegated zone

-      that does not have an authentication chain from its delegating

-      parent.  That is, there is no DS RR containing a hash of a DNSKEY

-      RR for the island in its delegating parent zone (see

-      [I-D.ietf-dnsext-dnssec-records]). An island of security is served

-      by security-aware name servers and may provide authentication

-      chains to any delegated child zones.  Responses from an island of

-      security or its descendents can only be authenticated if its

-      authentication keys can be authenticated by some trusted means out

-      of band from the DNS protocol.

-

-   Key Signing Key: An authentication key that corresponds to a private

-      key used to sign one or more other authentication keys for a given

-      zone.  Typically, the private key corresponding to a key signing

-      key will sign a zone signing key, which in turn has a

-      corresponding private key which will sign other zone data.  Local

-      policy may require the zone signing key to be changed frequently,

-      while the key signing key may have a longer validity period in

-      order to provide a more stable secure entry point into the zone.

-      Designating an authentication key as a key signing key is purely

-      an operational issue: DNSSEC validation does not distinguish

-      between key signing keys and other DNSSEC authentication keys, and

-      it is possible to use a single key as both a key signing key and a

-      zone signing key.  Key signing keys are discussed in more detail

-      in [RFC3757]. Also see: zone signing key.

-

-   Non-Validating Security-Aware Stub Resolver: A security-aware stub

-      resolver which trusts one or more security-aware recursive name

-      servers to perform most of the tasks discussed in this document

-      set on its behalf. In particular, a non-validating security-aware

-      stub resolver is an entity which sends DNS queries, receives DNS

-      responses, and is capable of establishing an appropriately secured

-      channel to a security-aware recursive name server which will

-      provide these services on behalf of the security-aware stub

-      resolver.  See also: security-aware stub resolver, validating

-      security-aware stub resolver.

-

-   Non-Validating Stub Resolver: A less tedious term for a

-      non-validating security-aware stub resolver.

-

-   Security-Aware Name Server: An entity acting in the role of a name

-      server (defined in section 2.4 of [RFC1034]) that understands the

-      DNS security extensions defined in this document set.  In

-      particular, a security-aware name server is an entity which

-      receives DNS queries, sends DNS responses, supports the EDNS0

-      [RFC2671] message size extension and the DO bit [RFC3225], and

-      supports the RR types and message header bits defined in this

-      document set.

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 5]

-

-

-   Security-Aware Recursive Name Server: An entity which acts in both

-      the security-aware name server and security-aware resolver roles.

-      A more cumbersome equivalent phrase would be "a security-aware

-      name server which offers recursive service".

-

-   Security-Aware Resolver: An entity acting in the role of a resolver

-      (defined in section 2.4 of [RFC1034]) which understands the DNS

-      security extensions defined in this document set.  In particular,

-      a security-aware resolver is an entity which sends DNS queries,

-      receives DNS responses, supports the EDNS0 [RFC2671] message size

-      extension and the DO bit [RFC3225], and is capable of using the RR

-      types and message header bits defined in this document set to

-      provide DNSSEC services.

-

-   Security-Aware Stub Resolver: An entity acting in the role of a stub

-      resolver (defined in section 5.3.1 of [RFC1034]) which has enough

-      of an understanding the DNS security extensions defined in this

-      document set to provide additional services not available from a

-      security-oblivious stub resolver.   Security-aware stub resolvers

-      may be either "validating" or "non-validating" depending on

-      whether the stub resolver attempts to verify DNSSEC signatures on

-      its own or trusts a friendly security-aware name server to do so.

-      See also: validating stub resolver, non-validating stub resolver.

-

-   Security-Oblivious <anything>: An <anything> that is not

-      "security-aware".

-

-   Signed Zone: A zone whose RRsets are signed and which contains

-      properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS

-      records.

-

-   Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A

-      validating security-aware resolver uses this public key or hash as

-      a starting point for building the authentication chain to a signed

-      DNS response.  In general, a validating resolver will need to

-      obtain the initial values of its trust anchors via some secure or

-      trusted means outside the DNS protocol.  Presence of a trust

-      anchor also implies that the resolver should expect the zone to

-      which the trust anchor points to be signed

-

-   Unsigned Zone: A zone that is not signed.

-

-   Validating Security-Aware Stub Resolver: A security-aware resolver

-      that sends queries in recursive mode but which performs signature

-      validation on its own rather than just blindly trusting an

-      upstream security-aware recursive name server.  See also:

-      security-aware stub resolver, non-validating security-aware stub

-      resolver.

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 6]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-   Validating Stub Resolver: A less tedious term for a validating

-      security-aware stub resolver.

-

-   Zone Signing Key: An authentication key that corresponds to a private

-      key used to sign a zone.  Typically a zone signing key will be

-      part of the same DNSKEY RRset as the key signing key whose

-      corresponding private key signs this DNSKEY RRset, but the zone

-      signing key is used for a slightly different purpose, and may

-      differ from the key signing key in other ways, such as validity

-      lifetime.  Designating an authentication key as a zone signing key

-      is purely an operational issue: DNSSEC validation does not

-      distinguish between zone signing keys and other DNSSEC

-      authentication keys, and it is possible to use a single key as

-      both a key signing key and a zone signing key.  See also: key

-      signing key.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 7]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-3.  Services Provided by DNS Security

-

-   The Domain Name System (DNS) security extensions provide origin

-   authentication and integrity assurance services for DNS data,

-   including mechanisms for authenticated denial of existence of DNS

-   data.  These mechanisms are described below.

-

-   These mechanisms require changes to the DNS protocol.  DNSSEC adds

-   four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two

-   new message header bits (CD and AD).  In order to support the larger

-   DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also

-   requires EDNS0 support [RFC2671].  Finally, DNSSEC requires support

-   for the DO bit [RFC3225], so that a security-aware resolver can

-   indicate in its queries that it wishes to receive DNSSEC RRs in

-   response messages.

-

-   These services protect against most of the threats to the Domain Name

-   System described in [I-D.ietf-dnsext-dns-threats].

-

-3.1  Data Origin Authentication and Data Integrity

-

-   DNSSEC provides authentication by associating cryptographically

-   generated digital signatures with DNS RRsets. These digital

-   signatures are stored in a new resource record, the RRSIG record.

-   Typically, there will be a single private key that signs a zone's

-   data, but multiple keys are possible: for example, there may be keys

-   for each of several different digital signature algorithms. If a

-   security-aware resolver reliably learns a zone's public key, it can

-   authenticate that zone's signed data.  An important DNSSEC concept is

-   that the key that signs a zone's data is associated with the zone

-   itself and not with the zone's authoritative name servers (public

-   keys for DNS transaction authentication mechanisms may also appear in

-   zones, as described in [RFC2931], but DNSSEC itself is concerned with

-   object security of DNS data, not channel security of DNS

-   transactions).

-

-   A security-aware resolver can learn a zone's public key either by

-   having a trust anchor configured into the resolver or by normal DNS

-   resolution.  To allow the latter, public keys are stored in a new

-   type of resource record, the DNSKEY RR.  Note that the private keys

-   used to sign zone data must be kept secure, and should be stored

-   offline when practical to do so.  To discover a public key reliably

-   via DNS resolution, the target key itself needs to be signed by

-   either a configured authentication key or another key that has been

-   authenticated previously. Security-aware resolvers authenticate zone

-   information by forming an authentication chain from a newly learned

-   public key back to a previously known authentication public key,

-   which in turn either has been configured into the resolver or must

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 8]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-   have been learned and verified previously.  Therefore, the resolver

-   must be configured with at least one trust anchor.  If the configured

-   key is a zone signing key, then it will authenticate the associated

-   zone; if the configured key is a key signing key, it will

-   authenticate a zone signing key.  If the resolver has been configured

-   with the hash of a key rather than the key itself, the resolver may

-   need to obtain the key via a DNS query.  To help security-aware

-   resolvers establish this authentication chain, security-aware name

-   servers attempt to send the signature(s) needed to authenticate a

-   zone's public key(s) in the DNS reply message along with the public

-   key itself, provided there is space available in the message.

-

-   The Delegation Signer (DS) RR type simplifies some of the

-   administrative tasks involved in signing delegations across

-   organizational boundaries.  The DS RRset resides at a delegation

-   point in a parent zone and indicates the public key(s) corresponding

-   to the private key(s) used to self-sign the DNSKEY RRset at the

-   delegated child zone's apex.  The administrator of the child zone, in

-   turn, uses the private key(s) corresponding to one or more of the

-   public keys in this DNSKEY RRset to sign the child zone's data.  The

-   typical authentication chain is therefore

-   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more

-   DS->DNSKEY subchains.  DNSSEC permits more complex authentication

-   chains, such as additional layers of DNSKEY RRs signing other DNSKEY

-   RRs within a zone.

-

-   A security-aware resolver normally constructs this authentication

-   chain from the root of the DNS hierarchy down to the leaf zones based

-   on configured knowledge of the public key for the root.  Local

-   policy, however, may also allow a security-aware resolver to use one

-   or more configured public keys (or hashes of public keys) other than

-   the root public key, or may not provide configured knowledge of the

-   root public key, or may prevent the resolver from using particular

-   public keys for arbitrary reasons even if those public keys are

-   properly signed with verifiable signatures.  DNSSEC provides

-   mechanisms by which a security-aware resolver can determine whether

-   an RRset's signature is "valid" within the meaning of DNSSEC. In the

-   final analysis however, authenticating both DNS keys and data is a

-   matter of local policy, which may extend or even override the

-   protocol extensions defined in this document set.  See  for further

-   discussion.

-

-3.2  Authenticating Name and Type Non-Existence

-

-   The security mechanism described in Section 3.1 only provides a way

-   to sign existing RRsets in a zone.  The problem of providing negative

-   responses with the same level of authentication and integrity

-   requires the use of another new resource record type, the NSEC

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 9]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-   record.  The NSEC record allows a security-aware resolver to

-   authenticate a negative reply for either name or type non-existence

-   via the same mechanisms used to authenticate other DNS replies.  Use

-   of NSEC records requires a canonical representation and ordering for

-   domain names in zones.  Chains of NSEC records explicitly describe

-   the gaps, or "empty space", between domain names in a zone, as well

-   as listing the types of RRsets present at existing names.  Each NSEC

-   record is signed and authenticated using the mechanisms described in

-   Section 3.1.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 10]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-4.  Services Not Provided by DNS Security

-

-   DNS was originally designed with the assumptions that the DNS will

-   return the same answer to any given query regardless of who may have

-   issued the query, and that all data in the DNS is thus visible.

-   Accordingly, DNSSEC is not designed to provide confidentiality,

-   access control lists, or other means of differentiating between

-   inquirers.

-

-   DNSSEC provides no protection against denial of service attacks.

-   Security-aware resolvers and security-aware name servers are

-   vulnerable to an additional class of denial of service attacks based

-   on cryptographic operations.  Please see Section 12 for details.

-

-   The DNS security extensions provide data and origin authentication

-   for DNS data.  The mechanisms outlined above are not designed to

-   protect operations such as zone transfers and dynamic update

-   [RFC3007].  Message authentication schemes described in [RFC2845] and

-   [RFC2931] address security operations that pertain to these

-   transactions.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 11]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-5.  Scope of the DNSSEC Document Set and Last Hop Issues

-

-   The specification in this document set defines the behavior for zone

-   signers and security-aware name servers and resolvers in such a way

-   that the validating entities can unambiguously determine the state of

-   the data.

-

-   A validating resolver can determine these 4 states:

-

-   Secure: The validating resolver has a trust anchor, a chain of trust

-      and is able to verify all the signatures in the response.

-

-   Insecure: The validating resolver has a trust anchor, a chain of

-      trust, and, at some delegation point, signed proof of the

-      non-existence of a DS record.  That indicates that subsequent

-      branches in the tree are provably insecure. A validating resolver

-      may have local policy to mark parts of the domain space as

-      insecure.

-

-   Bogus: The validating resolver has a trust anchor and there is a

-      secure delegation which is indicating that subsidiary data will be

-      signed, but the response fails to validate due to one or more

-      reasons: missing signatures, expired signatures, signatures with

-      unsupported algorithms, data missing which the relevant NSEC RR

-      says should be present, and so forth.

-

-   Indeterminate: There is no trust anchor which would indicate that a

-      specific portion of the tree is secure.  This is the default

-      operation mode.

-

-   This specification only defines how security aware name servers can

-   signal non-validating stub resolvers that data was found to be bogus

-   (using RCODE=2, "Server Failure" -- see

-   [I-D.ietf-dnsext-dnssec-protocol]).

-

-   There is a mechanism for security aware name servers to signal

-   security-aware stub resolvers that data was found to be secure (using

-   the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]).

-

-   This specification does not define a format for communicating why

-   responses were found to be bogus or marked as insecure. The current

-   signaling mechanism does not distinguish between indeterminate and

-   insecure.

-

-   A method for signaling advanced error codes and policy between a

-   security aware stub resolver and security aware recursive nameservers

-   is a topic for future work, as is the interface between a security

-   aware resolver and the applications that use it.  Note, however, that

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 12]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-   the lack of the specification of such communication does not prohibit

-   deployment of signed zones or the deployment of security aware

-   recursive name servers that prohibit propagation of bogus data to the

-   applications.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 13]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-6.  Resolver Considerations

-

-   A security-aware resolver needs to be able to perform cryptographic

-   functions necessary to verify digital signatures using at least the

-   mandatory-to-implement algorithm(s).  Security-aware resolvers must

-   also be capable of forming an authentication chain from a newly

-   learned zone back to an authentication key, as described above.  This

-   process might require additional queries to intermediate DNS zones to

-   obtain necessary DNSKEY, DS and RRSIG records.  A security-aware

-   resolver should be configured with at least one trust anchor as the

-   starting point from which it will attempt to establish authentication

-   chains.

-

-   If a security-aware resolver is separated from the relevant

-   authoritative name servers by a recursive name server or by any sort

-   of device which acts as a proxy for DNS, and if the recursive name

-   server or proxy is not security-aware, the security-aware resolver

-   may not be capable of operating in a secure mode.  For example, if a

-   security-aware resolver's packets are routed through a network

-   address translation device that includes a DNS proxy which is not

-   security-aware, the security-aware resolver may find it difficult or

-   impossible to obtain or validate signed DNS data.

-

-   If a security-aware resolver must rely on an unsigned zone or a name

-   server that is not security aware, the resolver may not be able to

-   validate DNS responses, and will need a local policy on whether to

-   accept unverified responses.

-

-   A security-aware resolver should take a signature's validation period

-   into consideration when determining the TTL of data in its cache, to

-   avoid caching signed data beyond the validity period of the

-   signature, but should also allow for the possibility that the

-   security-aware resolver's own clock is wrong.  Thus, a security-aware

-   resolver which is part of a security-aware recursive name server will

-   need to pay careful attention to the DNSSEC "checking disabled" (CD)

-   bit [I-D.ietf-dnsext-dnssec-records].  This is in order to avoid

-   blocking valid signatures from getting through to other

-   security-aware resolvers which are clients of this recursive name

-   server.  See [I-D.ietf-dnsext-dnssec-protocol] for how a secure

-   recursive server handles queries with the CD bit set.

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 14]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-7.  Stub Resolver Considerations

-

-   Although not strictly required to do so by the protocol, most DNS

-   queries originate from stub resolvers.  Stub resolvers, by

-   definition, are minimal DNS resolvers which use recursive query mode

-   to offload most of the work of DNS resolution to a recursive name

-   server.  Given the widespread use of stub resolvers, the DNSSEC

-   architecture has to take stub resolvers into account, but the

-   security features needed in a stub resolver differ in some respects

-   from those needed in a full security-aware resolver.

-

-   Even a security-oblivious stub resolver may get some benefit from

-   DNSSEC if the recursive name servers it uses are security-aware, but

-   for the stub resolver to place any real reliance on DNSSEC services,

-   the stub resolver must trust both the recursive name servers in

-   question and the communication channels between itself and those name

-   servers.  The first of these issues is a local policy issue: in

-   essence, a security-oblivious stub resolver has no real choice but to

-   place itself at the mercy of the recursive name servers that it uses,

-   since it does not perform DNSSEC validity checks on its own.  The

-   second issue requires some kind of channel security mechanism; proper

-   use of DNS transaction authentication mechanisms such as SIG(0) or

-   TSIG would suffice, as would appropriate use of IPsec, and particular

-   implementations may have other choices available, such as operating

-   system specific interprocess communication mechanisms.

-   Confidentiality is not needed for this channel, but data integrity

-   and message authentication are.

-

-   A security-aware stub resolver that does trust both its recursive

-   name servers and its communication channel to them may choose to

-   examine the setting of the AD bit in the message header of the

-   response messages it receives.  The stub resolver can use this flag

-   bit as a hint to find out whether the recursive name server was able

-   to validate signatures for all of the data in the Answer and

-   Authority sections of the response.

-

-   There is one more step that a security-aware stub resolver can take

-   if, for whatever reason, it is not able to establish a useful trust

-   relationship with the recursive name servers which it uses: it can

-   perform its own signature validation, by setting the Checking

-   Disabled (CD) bit in its query messages.  A validating stub resolver

-   is thus able to treat the DNSSEC signatures as a trust relationship

-   between the zone administrator and the stub resolver itself.

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 15]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-8.  Zone Considerations

-

-   There are several differences between signed and unsigned zones.  A

-   signed zone will contain additional security-related records (RRSIG,

-   DNSKEY, DS and NSEC records).  RRSIG and NSEC records may be

-   generated by a signing process prior to serving the zone.  The RRSIG

-   records that accompany zone data have defined inception and

-   expiration times, which establish a validity period for the

-   signatures and the zone data the signatures cover.

-

-8.1  TTL values vs. RRSIG validity period

-

-   It is important to note the distinction between a RRset's TTL value

-   and the signature validity period specified by the RRSIG RR covering

-   that RRset.  DNSSEC does not change the definition or function of the

-   TTL value, which is intended to maintain database coherency in

-   caches. A caching resolver purges RRsets from its cache no later than

-   the end of the time period specified by the TTL fields of those

-   RRsets, regardless of whether or not the resolver is security-aware.

-

-   The inception and expiration fields in the RRSIG RR

-   [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time

-   period during which the signature can be used to validate the covered

-   RRset.  The signatures associated with signed zone data are only

-   valid for the time period specified by these fields in the RRSIG RRs

-   in question.  TTL values cannot extend the validity period of signed

-   RRsets in a resolver's cache, but the resolver may use the time

-   remaining before expiration of the signature validity period of a

-   signed RRset as an upper bound for the TTL of the signed RRset and

-   its associated RRSIG RR in the resolver's cache.

-

-8.2  New Temporal Dependency Issues for Zones

-

-   Information in a signed zone has a temporal dependency which did not

-   exist in the original DNS protocol.  A signed zone requires regular

-   maintenance to ensure that each RRset in the zone has a current valid

-   RRSIG RR.  The signature validity period of an RRSIG RR is an

-   interval during which the signature for one particular signed RRset

-   can be considered valid, and the signatures of different RRsets in a

-   zone may expire at different times.  Re-signing one or more RRsets in

-   a zone will change one or more RRSIG RRs, which in turn will require

-   incrementing the zone's SOA serial number to indicate that a zone

-   change has occurred and re-signing the SOA RRset itself.  Thus,

-   re-signing any RRset in a zone may also trigger DNS NOTIFY messages

-   and zone transfers operations.

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 16]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-9.  Name Server Considerations

-

-   A security-aware name server should include the appropriate DNSSEC

-   records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from

-   resolvers which have signaled their willingness to receive such

-   records via use of the DO bit in the EDNS header, subject to message

-   size limitations.  Since inclusion of these DNSSEC RRs could easily

-   cause UDP message truncation and fallback to TCP, a security-aware

-   name server must also support the EDNS "sender's UDP payload"

-   mechanism.

-

-   If possible, the private half of each DNSSEC key pair should be kept

-   offline, but this will not be possible for a zone for which DNS

-   dynamic update has been enabled.  In the dynamic update case, the

-   primary master server for the zone will have to re-sign the zone when

-   updated, so the private key corresponding to the zone signing key

-   will have to be kept online.  This is an example of a situation where

-   the ability to separate the zone's DNSKEY RRset into zone signing

-   key(s) and key signing key(s) may be useful, since the key signing

-   key(s) in such a case can still be kept offline and may have a longer

-   useful lifetime than the zone signing key(s).

-

-   DNSSEC, by itself, is not enough to protect the integrity of an

-   entire zone during zone transfer operations, since even a signed zone

-   contains some unsigned, nonauthoritative data if the zone has any

-   children.  Therefore, zone maintenance operations will require some

-   additional mechanisms (most likely some form of channel security,

-   such as TSIG, SIG(0), or IPsec).

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 17]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-10.  DNS Security Document Family

-

-   The DNSSEC document set can be partitioned into several main groups,

-   under the larger umbrella of the DNS base protocol documents.

-

-   The "DNSSEC protocol document set" refers to the three documents

-   which form the core of the DNS security extensions:

-   1.  DNS Security Introduction and Requirements (this document)

-   2.  Resource Records for DNS Security Extensions

-       [I-D.ietf-dnsext-dnssec-records]

-   3.  Protocol Modifications for the DNS Security Extensions

-       [I-D.ietf-dnsext-dnssec-protocol]

-

-   Additionally, any document that would add to, or change the core DNS

-   Security extensions would fall into this category.  This includes any

-   future work on the communication between security-aware stub

-   resolvers and upstream security-aware recursive name servers.

-

-   The "Digital Signature Algorithm Specification" document set refers

-   to the group of documents that describe how specific digital

-   signature algorithms should be implemented to fit the DNSSEC resource

-   record format.  Each document in this set deals with a specific

-   digital signature algorithm.

-

-   The "Transaction Authentication Protocol" document set refers to the

-   group of documents that deal with DNS message authentication,

-   including secret key establishment and verification.  While not

-   strictly part of the DNSSEC specification as defined in this set of

-   documents, this group is noted because of its relationship to DNSSEC.

-

-   The final document set, "New Security Uses", refers to documents that

-   seek to use proposed DNS Security extensions for other security

-   related purposes.  DNSSEC does not provide any direct security for

-   these new uses, but may be used to support them.  Documents that fall

-   in this category include the use of DNS in the storage and

-   distribution of certificates [RFC2538].

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 18]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-11.  IANA Considerations

-

-   This overview document introduces no new IANA considerations. Please

-   see [I-D.ietf-dnsext-dnssec-records] for a complete review of the

-   IANA considerations introduced by DNSSEC.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 19]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-12.  Security Considerations

-

-   This document introduces the DNS security extensions and describes

-   the document set that contains the new security records and DNS

-   protocol modifications.  The extensions provide data origin

-   authentication and data integrity using digital signatures over

-   resource record sets.This document discusses the capabilities and

-   limitations of these extensions.

-

-   In order for a security-aware resolver to validate a DNS response,

-   all zones along the path from the trusted starting point to the zone

-   containing the response zones must be signed, and all name servers

-   and resolvers involved in the resolution process must be

-   security-aware, as defined in this document set.  A security-aware

-   resolver cannot verify responses originating from an unsigned zone,

-   from a zone not served by a security-aware name server, or for any

-   DNS data which the resolver is only able to obtain through a

-   recursive name server which is not security-aware.  If there is a

-   break in the authentication chain such that a security-aware resolver

-   cannot obtain and validate the authentication keys it needs, then the

-   security-aware resolver cannot validate the affected DNS data.

-

-   This document briefly discusses other methods of adding security to a

-   DNS query, such as using a channel secured by IPsec or using a DNS

-   transaction authentication mechanism, but transaction security is not

-   part of DNSSEC per se.

-

-   A non-validating security-aware stub resolver, by definition, does

-   not perform DNSSEC signature validation on its own, and thus is

-   vulnerable both to attacks on (and by) the security-aware recursive

-   name servers which perform these checks on its behalf and also to

-   attacks on its communication with those security-aware recursive name

-   servers. Non-validating security-aware stub resolvers should use some

-   form of channel security to defend against the latter threat. The

-   only known defense against the former threat would be for the

-   security-aware stub resolver to perform its own signature validation,

-   at which point, again by definition, it would no longer be a

-   non-validating security-aware stub resolver.

-

-   DNSSEC does not protect against denial of service attacks.  DNSSEC

-   makes DNS vulnerable to a new class of denial of service attacks

-   based on cryptographic operations against security-aware resolvers

-   and security-aware name servers, since an attacker can attempt to use

-   DNSSEC mechanisms to consume a victim's resources.  This class of

-   attacks takes at least two forms.  An attacker may be able to consume

-   resources in a security-aware resolver's signature validation code by

-   tampering with RRSIG RRs in response messages or by constructing

-   needlessly complex signature chains.  An attacker may also be able to

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 20]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-   consume resources in a security-aware name server which supports DNS

-   dynamic update, by sending a stream of update messages that force the

-   security-aware name server to re-sign some RRsets in the zone more

-   frequently than would otherwise be necessary.

-

-   DNSSEC introduces the ability for a hostile party to enumerate all

-   the names in a zone by following the NSEC chain. NSEC RRs assert

-   which names do not exist in a zone by linking from existing name to

-   existing name along a canonical ordering of all the names within a

-   zone. Thus, an attacker can query these NSEC RRs in sequence to

-   obtain all the names in a zone. While not an attack on the DNS

-   itself, this could allow an attacker to map network hosts or other

-   resources by enumerating the contents of a zone. There are non-DNS

-   protocol means of detecting and limiting this attack beyond the scope

-   of this document set.

-

-   DNSSEC introduces significant additional complexity to the DNS, and

-   thus introduces many new opportunities for implementation bugs and

-   misconfigured zones.  In particular, enabling DNSSEC signature

-   validation in a resolver may cause entire legitimate zones to become

-   effectively unreachable due to DNSSEC configuration errors or bugs.

-

-   DNSSEC does not provide confidentiality, due to a deliberate design

-   choice.

-

-   DNSSEC does not protect against tampering with unsigned zone data.

-   Non-authoritative data at zone cuts (glue and NS RRs in the parent

-   zone) are not signed.  This does not pose a problem when validating

-   the authentication chain, but does mean that the non-authoritative

-   data itself is vulnerable to tampering during zone transfer

-   operations.  Thus, while DNSSEC can provide data origin

-   authentication and data integrity for RRsets, it cannot do so for

-   zones, and other mechanisms must be used to protect zone transfer

-   operations.

-

-   Please see [I-D.ietf-dnsext-dnssec-records] and

-   [I-D.ietf-dnsext-dnssec-protocol] for additional security

-   considerations.

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 21]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-13.  Acknowledgements

-

-   This document was created from the input and ideas of the members of

-   the DNS Extensions Working Group.  While explicitly listing everyone

-   who has contributed during the decade during which DNSSEC has been

-   under development would be an impossible task, the editors would

-   particularly like to thank the following people for their

-   contributions to and comments on this document set: Mark Andrews,

-   Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney,

-   Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael

-   Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip

-   Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf

-   Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted

-   Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson,

-   Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik

-   Rozendaal, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, and

-   Brian Wellington.

-

-   No doubt the above list is incomplete.  We apologize to anyone we

-   left out.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 22]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-14.  References

-

-14.1  Normative References

-

-   [I-D.ietf-dnsext-dnssec-protocol]

-              Arends, R., Austein, R., Larson, M., Massey, D. and S.

-              Rose, "Protocol Modifications for the DNS Security

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

-              progress), May 2004.

-

-   [I-D.ietf-dnsext-dnssec-records]

-              Arends, R., Austein, R., Larson, M., Massey, D. and S.

-              Rose, "Resource Records for DNS Security Extensions",

-              draft-ietf-dnsext-dnssec-records-08 (work in progress),

-              May 2004.

-

-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",

-              STD 13, RFC 1034, November 1987.

-

-   [RFC1035]  Mockapetris, P., "Domain names - implementation and

-              specification", STD 13, RFC 1035, November 1987.

-

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

-              RFC 2535, March 1999.

-

-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC

-              2671, August 1999.

-

-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC

-              3225, December 2001.

-

-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver

-              message size requirements", RFC 3226, December 2001.

-

-   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY

-              Resource Record (RR)", RFC 3445, December 2002.

-

-14.2  Informative References

-

-   [I-D.ietf-dnsext-dns-threats]

-              Atkins, D. and R. Austein, "Threat Analysis Of The Domain

-              Name System", draft-ietf-dnsext-dns-threats-07 (work in

-              progress), April 2004.

-

-   [I-D.ietf-dnsext-nsec-rdata]

-              Schlyter, J., "KEY RR Secure Entry Point Flag",

-              draft-ietf-dnsext-nsec-rdata-05 (work in progress), March

-              2004.

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 23]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic

-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,

-              April 1997.

-

-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS

-              Specification", RFC 2181, July 1997.

-

-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS

-              NCACHE)", RFC 2308, March 1998.

-

-   [RFC2538]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in

-              the Domain Name System (DNS)", RFC 2538, March 1999.

-

-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.

-              Wellington, "Secret Key Transaction Authentication for DNS

-              (TSIG)", RFC 2845, May 2000.

-

-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (

-              SIG(0)s)", RFC 2931, September 2000.

-

-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic

-              Update", RFC 3007, November 2000.

-

-   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)

-              Signing Authority", RFC 3008, November 2000.

-

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

-              Status", RFC 3090, March 2001.

-

-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record

-              (RR) Types", RFC 3597, September 2003.

-

-   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS

-              Authenticated Data (AD) bit", RFC 3655, November 2003.

-

-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record

-              (RR)", RFC 3658, December 2003.

-

-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation

-              Signer", RFC 3755, April 2004.

-

-   [RFC3757]  Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure

-              Entry Point Flag", RFC 3757, April 2004.

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 24]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-Authors' Addresses

-

-   Roy Arends

-   Telematica Instituut

-   Drienerlolaan 5

-   7522 NB  Enschede

-   NL

-

-   EMail: roy.arends@telin.nl

-

-

-   Rob Austein

-   Internet Systems Consortium

-   950 Charter Street

-   Redwood City, CA  94063

-   USA

-

-   EMail: sra@isc.org

-

-

-   Matt Larson

-   VeriSign, Inc.

-   21345 Ridgetop Circle

-   Dulles, VA  20166-6503

-   USA

-

-   EMail: mlarson@verisign.com

-

-

-   Dan Massey

-   USC Information Sciences Institute

-   3811 N. Fairfax Drive

-   Arlington, VA  22203

-   USA

-

-   EMail: masseyd@isi.edu

-

-

-   Scott Rose

-   National Institute for Standards and Technology

-   100 Bureau Drive

-   Gaithersburg, MD  20899-8920

-   USA

-

-   EMail: scott.rose@nist.gov

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 25]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

-Intellectual Property Statement

-

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

-   intellectual property or other rights that might be claimed to

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

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

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

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

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

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

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

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

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

-   proprietary rights by implementors or users of this specification can

-   be obtained from the IETF Secretariat.

-

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

-   copyrights, patents or patent applications, or other proprietary

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

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

-   Director.

-

-

-Full Copyright Statement

-

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

-

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

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

-   or assist in its implementation may be prepared, copied, published

-   and distributed, in whole or in part, without restriction of any

-   kind, provided that the above copyright notice and this paragraph are

-   included on all such copies and derivative works. However, this

-   document itself may not be modified in any way, such as by removing

-   the copyright notice or references to the Internet Society or other

-   Internet organizations, except as needed for the purpose of

-   developing Internet standards in which case the procedures for

-   copyrights defined in the Internet Standards process must be

-   followed, or as required to translate it into languages other than

-   English.

-

-   The limited permissions granted above are perpetual and will not be

-   revoked by the Internet Society or its successors or assignees.

-

-   This document and the information contained herein is provided on an

-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 26]

-

-Internet-Draft    DNSSEC Introduction and Requirements          May 2004

-

-

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

-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Acknowledgment

-

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

-   Internet Society.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 27]

-

-

+
+
+DNS Extensions                                                 R. Arends
+Internet-Draft                                      Telematica Instituut
+Expires: January 13, 2005                                     R. Austein
+                                                                     ISC
+                                                               M. Larson
+                                                                VeriSign
+                                                               D. Massey
+                                                                 USC/ISI
+                                                                 S. Rose
+                                                                    NIST
+                                                           July 15, 2004
+
+
+               DNS Security Introduction and Requirements
+                   draft-ietf-dnsext-dnssec-intro-11
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 13, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   The Domain Name System Security Extensions (DNSSEC) add data origin
+   authentication and data integrity to the Domain Name System.  This
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 1]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+   document introduces these extensions, and describes their
+   capabilities and limitations.  This document also discusses the
+   services that the DNS security extensions do and do not provide.
+   Last, this document describes the interrelationships between the
+   group of documents that collectively describe DNSSEC.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . . .  4
+   3.  Services Provided by DNS Security  . . . . . . . . . . . . . .  8
+     3.1   Data Origin Authentication and Data Integrity  . . . . . .  8
+     3.2   Authenticating Name and Type Non-Existence . . . . . . . .  9
+   4.  Services Not Provided by DNS Security  . . . . . . . . . . . . 11
+   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12
+   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . . . 14
+   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15
+   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . . . 16
+     8.1   TTL values vs. RRSIG validity period . . . . . . . . . . . 16
+     8.2   New Temporal Dependency Issues for Zones . . . . . . . . . 16
+   9.  Name Server Considerations . . . . . . . . . . . . . . . . . . 17
+   10.   DNS Security Document Family . . . . . . . . . . . . . . . . 18
+   11.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 19
+   12.   Security Considerations  . . . . . . . . . . . . . . . . . . 20
+   13.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
+   14.   References . . . . . . . . . . . . . . . . . . . . . . . . . 23
+   14.1  Normative References . . . . . . . . . . . . . . . . . . . . 23
+   14.2  Informative References . . . . . . . . . . . . . . . . . . . 23
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
+       Intellectual Property and Copyright Statements . . . . . . . . 26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 2]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+1.  Introduction
+
+   This document introduces the Domain Name System Security Extensions
+   (DNSSEC).  This document and its two companion documents
+   ([I-D.ietf-dnsext-dnssec-records] and
+   [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
+   security extensions defined in RFC 2535 [RFC2535] and its
+   predecessors.  These security extensions consist of a set of new
+   resource record types and modifications to the existing DNS protocol
+   [RFC1035].  The new records and protocol modifications are not fully
+   described in this document, but are described in a family of
+   documents outlined in Section 10.  Section 3 and Section 4 describe
+   the capabilities and limitations of the security extensions in
+   greater detail.  Section 5 discusses the scope of the document set.
+   Section 6, Section 7, Section 8, and Section 9 discuss the effect
+   that these security extensions will have on resolvers, stub
+   resolvers, zones and name servers.
+
+   This document and its two companions update and obsolete RFCs 2535
+   [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655
+   [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress
+   [I-D.ietf-dnsext-nsec-rdata].  This document set also updates, but
+   does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
+   [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts
+   of 3226 [RFC3226] (dealing with DNSSEC).
+
+   The DNS security extensions provide origin authentication and
+   integrity protection for DNS data, as well as a means of public key
+   distribution.  These extensions do not provide confidentiality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 3]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+2.  Definitions of Important DNSSEC Terms
+
+   This section defines a number of terms used in this document set.
+   Since this is intended to be useful as a reference while reading the
+   rest of the document set, first-time readers may wish to skim this
+   section quickly, read the rest of this document, then come back to
+   this section.
+
+   Authentication Chain: An alternating sequence of DNSKEY RRsets and DS
+      RRsets forms a chain of signed data, with each link in the chain
+      vouching for the next.  A DNSKEY RR is used to verify the
+      signature covering a DS RR and allows the DS RR to be
+      authenticated.  The DS RR contains a hash of another DNSKEY RR and
+      this new DNSKEY RR is authenticated by matching the hash in the DS
+      RR.  This new DNSKEY RR in turn authenticates another DNSKEY RRset
+      and, in turn, some DNSKEY RR in this set may be used to
+      authenticate another DS RR and so forth until the chain finally
+      ends with a DNSKEY RR whose corresponding private key signs the
+      desired DNS data.  For example, the root DNSKEY RRset can be used
+      to authenticate the DS RRset for "example."  The "example." DS
+      RRset contains a hash that matches some "example." DNSKEY, and
+      this DNSKEY's corresponding private key signs the "example."
+      DNSKEY RRset.  Private key counterparts of the "example." DNSKEY
+      RRset sign data records such as "www.example." as well as DS RRs
+      for delegations such as "subzone.example."
+
+   Authentication Key: A public key that a security-aware resolver has
+      verified and can therefore use to authenticate data.  A
+      security-aware resolver can obtain authentication keys in three
+      ways.  First, the resolver is generally configured to know about
+      at least one public key; this configured data is usually either
+      the public key itself or a hash of the public key as found in the
+      DS RR (see "trust anchor").  Second, the resolver may use an
+      authenticated public key to verify a DS RR and the DNSKEY RR to
+      which the DS RR refers.  Third, the resolver may be able to
+      determine that a new public key has been signed by the private key
+      corresponding to another public key which the resolver has
+      verified.  Note that the resolver must always be guided by local
+      policy when deciding whether to authenticate a new public key,
+      even if the local policy is simply to authenticate any new public
+      key for which the resolver is able verify the signature.
+
+   Delegation Point: Term used to describe the name at the parental side
+      of a zone cut.  That is, the delegation point for "foo.example"
+      would be the foo.example node in the "example" zone (as opposed to
+      the zone apex of the "foo.example" zone).
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 4]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+   Island of Security: Term used to describe a signed, delegated zone
+      that does not have an authentication chain from its delegating
+      parent.  That is, there is no DS RR containing a hash of a DNSKEY
+      RR for the island in its delegating parent zone (see
+      [I-D.ietf-dnsext-dnssec-records]).  An island of security is
+      served by security-aware name servers and may provide
+      authentication chains to any delegated child zones.  Responses
+      from an island of security or its descendents can only be
+      authenticated if its authentication keys can be authenticated by
+      some trusted means out of band from the DNS protocol.
+
+   Key Signing Key (KSK): An authentication key that corresponds to a
+      private key used to sign one or more other authentication keys for
+      a given zone.  Typically, the private key corresponding to a key
+      signing key will sign a zone signing key, which in turn has a
+      corresponding private key which will sign other zone data.  Local
+      policy may require the zone signing key to be changed frequently,
+      while the key signing key may have a longer validity period in
+      order to provide a more stable secure entry point into the zone.
+      Designating an authentication key as a key signing key is purely
+      an operational issue: DNSSEC validation does not distinguish
+      between key signing keys and other DNSSEC authentication keys, and
+      it is possible to use a single key as both a key signing key and a
+      zone signing key.  Key signing keys are discussed in more detail
+      in [RFC3757].  Also see: zone signing key.
+
+   Non-Validating Security-Aware Stub Resolver: A security-aware stub
+      resolver which trusts one or more security-aware recursive name
+      servers to perform most of the tasks discussed in this document
+      set on its behalf.  In particular, a non-validating security-aware
+      stub resolver is an entity which sends DNS queries, receives DNS
+      responses, and is capable of establishing an appropriately secured
+      channel to a security-aware recursive name server which will
+      provide these services on behalf of the security-aware stub
+      resolver.  See also: security-aware stub resolver, validating
+      security-aware stub resolver.
+
+   Non-Validating Stub Resolver: A less tedious term for a
+      non-validating security-aware stub resolver.
+
+   Security-Aware Name Server: An entity acting in the role of a name
+      server (defined in section 2.4 of [RFC1034]) that understands the
+      DNS security extensions defined in this document set.  In
+      particular, a security-aware name server is an entity which
+      receives DNS queries, sends DNS responses, supports the EDNS0
+      [RFC2671] message size extension and the DO bit [RFC3225], and
+      supports the RR types and message header bits defined in this
+      document set.
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 5]
+
+
+   Security-Aware Recursive Name Server: An entity which acts in both
+      the security-aware name server and security-aware resolver roles.
+      A more cumbersome equivalent phrase would be "a security-aware
+      name server which offers recursive service".
+
+   Security-Aware Resolver: An entity acting in the role of a resolver
+      (defined in section 2.4 of [RFC1034]) which understands the DNS
+      security extensions defined in this document set.  In particular,
+      a security-aware resolver is an entity which sends DNS queries,
+      receives DNS responses, supports the EDNS0 [RFC2671] message size
+      extension and the DO bit [RFC3225], and is capable of using the RR
+      types and message header bits defined in this document set to
+      provide DNSSEC services.
+
+   Security-Aware Stub Resolver: An entity acting in the role of a stub
+      resolver (defined in section 5.3.1 of [RFC1034]) which has enough
+      of an understanding the DNS security extensions defined in this
+      document set to provide additional services not available from a
+      security-oblivious stub resolver.  Security-aware stub resolvers
+      may be either "validating" or "non-validating" depending on
+      whether the stub resolver attempts to verify DNSSEC signatures on
+      its own or trusts a friendly security-aware name server to do so.
+      See also: validating stub resolver, non-validating stub resolver.
+
+   Security-Oblivious <anything>: An <anything> that is not
+      "security-aware".
+
+   Signed Zone: A zone whose RRsets are signed and which contains
+      properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
+      records.
+
+   Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
+      validating security-aware resolver uses this public key or hash as
+      a starting point for building the authentication chain to a signed
+      DNS response.  In general, a validating resolver will need to
+      obtain the initial values of its trust anchors via some secure or
+      trusted means outside the DNS protocol.  Presence of a trust
+      anchor also implies that the resolver should expect the zone to
+      which the trust anchor points to be signed.
+
+   Unsigned Zone: A zone that is not signed.
+
+   Validating Security-Aware Stub Resolver: A security-aware resolver
+      that sends queries in recursive mode but which performs signature
+      validation on its own rather than just blindly trusting an
+      upstream security-aware recursive name server.  See also:
+      security-aware stub resolver, non-validating security-aware stub
+      resolver.
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 6]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+   Validating Stub Resolver: A less tedious term for a validating
+      security-aware stub resolver.
+
+   Zone Signing Key (ZSK): An authentication key that corresponds to a
+      private key used to sign a zone.  Typically a zone signing key
+      will be part of the same DNSKEY RRset as the key signing key whose
+      corresponding private key signs this DNSKEY RRset, but the zone
+      signing key is used for a slightly different purpose, and may
+      differ from the key signing key in other ways, such as validity
+      lifetime.  Designating an authentication key as a zone signing key
+      is purely an operational issue: DNSSEC validation does not
+      distinguish between zone signing keys and other DNSSEC
+      authentication keys, and it is possible to use a single key as
+      both a key signing key and a zone signing key.  See also: key
+      signing key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 7]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+3.  Services Provided by DNS Security
+
+   The Domain Name System (DNS) security extensions provide origin
+   authentication and integrity assurance services for DNS data,
+   including mechanisms for authenticated denial of existence of DNS
+   data.  These mechanisms are described below.
+
+   These mechanisms require changes to the DNS protocol.  DNSSEC adds
+   four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two
+   new message header bits (CD and AD).  In order to support the larger
+   DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
+   requires EDNS0 support [RFC2671].  Finally, DNSSEC requires support
+   for the DO bit [RFC3225], so that a security-aware resolver can
+   indicate in its queries that it wishes to receive DNSSEC RRs in
+   response messages.
+
+   These services protect against most of the threats to the Domain Name
+   System described in [I-D.ietf-dnsext-dns-threats].
+
+3.1  Data Origin Authentication and Data Integrity
+
+   DNSSEC provides authentication by associating cryptographically
+   generated digital signatures with DNS RRsets.  These digital
+   signatures are stored in a new resource record, the RRSIG record.
+   Typically, there will be a single private key that signs a zone's
+   data, but multiple keys are possible: for example, there may be keys
+   for each of several different digital signature algorithms.  If a
+   security-aware resolver reliably learns a zone's public key, it can
+   authenticate that zone's signed data.  An important DNSSEC concept is
+   that the key that signs a zone's data is associated with the zone
+   itself and not with the zone's authoritative name servers (public
+   keys for DNS transaction authentication mechanisms may also appear in
+   zones, as described in [RFC2931], but DNSSEC itself is concerned with
+   object security of DNS data, not channel security of DNS
+   transactions.  The keys associated with transaction security may be
+   stored in different RR types.  See [RFC3755] for details.).
+
+   A security-aware resolver can learn a zone's public key either by
+   having a trust anchor configured into the resolver or by normal DNS
+   resolution.  To allow the latter, public keys are stored in a new
+   type of resource record, the DNSKEY RR.  Note that the private keys
+   used to sign zone data must be kept secure, and should be stored
+   offline when practical to do so.  To discover a public key reliably
+   via DNS resolution, the target key itself needs to be signed by
+   either a configured authentication key or another key that has been
+   authenticated previously.  Security-aware resolvers authenticate zone
+   information by forming an authentication chain from a newly learned
+   public key back to a previously known authentication public key,
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 8]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+   which in turn either has been configured into the resolver or must
+   have been learned and verified previously.  Therefore, the resolver
+   must be configured with at least one trust anchor.  If the configured
+   key is a zone signing key, then it will authenticate the associated
+   zone; if the configured key is a key signing key, it will
+   authenticate a zone signing key.  If the resolver has been configured
+   with the hash of a key rather than the key itself, the resolver may
+   need to obtain the key via a DNS query.  To help security-aware
+   resolvers establish this authentication chain, security-aware name
+   servers attempt to send the signature(s) needed to authenticate a
+   zone's public key(s) in the DNS reply message along with the public
+   key itself, provided there is space available in the message.
+
+   The Delegation Signer (DS) RR type simplifies some of the
+   administrative tasks involved in signing delegations across
+   organizational boundaries.  The DS RRset resides at a delegation
+   point in a parent zone and indicates the public key(s) corresponding
+   to the private key(s) used to self-sign the DNSKEY RRset at the
+   delegated child zone's apex.  The administrator of the child zone, in
+   turn, uses the private key(s) corresponding to one or more of the
+   public keys in this DNSKEY RRset to sign the child zone's data.  The
+   typical authentication chain is therefore
+   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
+   DS->DNSKEY subchains.  DNSSEC permits more complex authentication
+   chains, such as additional layers of DNSKEY RRs signing other DNSKEY
+   RRs within a zone.
+
+   A security-aware resolver normally constructs this authentication
+   chain from the root of the DNS hierarchy down to the leaf zones based
+   on configured knowledge of the public key for the root.  Local
+   policy, however, may also allow a security-aware resolver to use one
+   or more configured public keys (or hashes of public keys) other than
+   the root public key, or may not provide configured knowledge of the
+   root public key, or may prevent the resolver from using particular
+   public keys for arbitrary reasons even if those public keys are
+   properly signed with verifiable signatures.  DNSSEC provides
+   mechanisms by which a security-aware resolver can determine whether
+   an RRset's signature is "valid" within the meaning of DNSSEC.  In the
+   final analysis however, authenticating both DNS keys and data is a
+   matter of local policy, which may extend or even override the
+   protocol extensions defined in this document set.  See Section 5 for
+   further discussion.
+
+3.2  Authenticating Name and Type Non-Existence
+
+   The security mechanism described in Section 3.1 only provides a way
+   to sign existing RRsets in a zone.  The problem of providing negative
+   responses with the same level of authentication and integrity
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 9]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+   requires the use of another new resource record type, the NSEC
+   record.  The NSEC record allows a security-aware resolver to
+   authenticate a negative reply for either name or type non-existence
+   via the same mechanisms used to authenticate other DNS replies.  Use
+   of NSEC records requires a canonical representation and ordering for
+   domain names in zones.  Chains of NSEC records explicitly describe
+   the gaps, or "empty space", between domain names in a zone, as well
+   as listing the types of RRsets present at existing names.  Each NSEC
+   record is signed and authenticated using the mechanisms described in
+   Section 3.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 10]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+4.  Services Not Provided by DNS Security
+
+   DNS was originally designed with the assumptions that the DNS will
+   return the same answer to any given query regardless of who may have
+   issued the query, and that all data in the DNS is thus visible.
+   Accordingly, DNSSEC is not designed to provide confidentiality,
+   access control lists, or other means of differentiating between
+   inquirers.
+
+   DNSSEC provides no protection against denial of service attacks.
+   Security-aware resolvers and security-aware name servers are
+   vulnerable to an additional class of denial of service attacks based
+   on cryptographic operations.  Please see Section 12 for details.
+
+   The DNS security extensions provide data and origin authentication
+   for DNS data.  The mechanisms outlined above are not designed to
+   protect operations such as zone transfers and dynamic update
+   [RFC3007].  Message authentication schemes described in [RFC2845] and
+   [RFC2931] address security operations that pertain to these
+   transactions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 11]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+5.  Scope of the DNSSEC Document Set and Last Hop Issues
+
+   The specification in this document set defines the behavior for zone
+   signers and security-aware name servers and resolvers in such a way
+   that the validating entities can unambiguously determine the state of
+   the data.
+
+   A validating resolver can determine these 4 states:
+
+   Secure: The validating resolver has a trust anchor, a chain of trust
+      and is able to verify all the signatures in the response.
+
+   Insecure: The validating resolver has a trust anchor, a chain of
+      trust, and, at some delegation point, signed proof of the
+      non-existence of a DS record.  That indicates that subsequent
+      branches in the tree are provably insecure.  A validating resolver
+      may have local policy to mark parts of the domain space as
+      insecure.
+
+   Bogus: The validating resolver has a trust anchor and there is a
+      secure delegation which is indicating that subsidiary data will be
+      signed, but the response fails to validate due to one or more
+      reasons: missing signatures, expired signatures, signatures with
+      unsupported algorithms, data missing which the relevant NSEC RR
+      says should be present, and so forth.
+
+   Indeterminate: There is no trust anchor which would indicate that a
+      specific portion of the tree is secure.  This is the default
+      operation mode.
+
+   This specification only defines how security aware name servers can
+   signal non-validating stub resolvers that data was found to be bogus
+   (using RCODE=2, "Server Failure" -- see
+   [I-D.ietf-dnsext-dnssec-protocol]).
+
+   There is a mechanism for security aware name servers to signal
+   security-aware stub resolvers that data was found to be secure (using
+   the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]).
+
+   This specification does not define a format for communicating why
+   responses were found to be bogus or marked as insecure.  The current
+   signaling mechanism does not distinguish between indeterminate and
+   insecure.
+
+   A method for signaling advanced error codes and policy between a
+   security aware stub resolver and security aware recursive nameservers
+   is a topic for future work, as is the interface between a security
+   aware resolver and the applications that use it.  Note, however, that
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 12]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+   the lack of the specification of such communication does not prohibit
+   deployment of signed zones or the deployment of security aware
+   recursive name servers that prohibit propagation of bogus data to the
+   applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 13]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+6.  Resolver Considerations
+
+   A security-aware resolver needs to be able to perform cryptographic
+   functions necessary to verify digital signatures using at least the
+   mandatory-to-implement algorithm(s).  Security-aware resolvers must
+   also be capable of forming an authentication chain from a newly
+   learned zone back to an authentication key, as described above.  This
+   process might require additional queries to intermediate DNS zones to
+   obtain necessary DNSKEY, DS and RRSIG records.  A security-aware
+   resolver should be configured with at least one trust anchor as the
+   starting point from which it will attempt to establish authentication
+   chains.
+
+   If a security-aware resolver is separated from the relevant
+   authoritative name servers by a recursive name server or by any sort
+   of device which acts as a proxy for DNS, and if the recursive name
+   server or proxy is not security-aware, the security-aware resolver
+   may not be capable of operating in a secure mode.  For example, if a
+   security-aware resolver's packets are routed through a network
+   address translation device that includes a DNS proxy which is not
+   security-aware, the security-aware resolver may find it difficult or
+   impossible to obtain or validate signed DNS data.
+
+   If a security-aware resolver must rely on an unsigned zone or a name
+   server that is not security aware, the resolver may not be able to
+   validate DNS responses, and will need a local policy on whether to
+   accept unverified responses.
+
+   A security-aware resolver should take a signature's validation period
+   into consideration when determining the TTL of data in its cache, to
+   avoid caching signed data beyond the validity period of the
+   signature, but should also allow for the possibility that the
+   security-aware resolver's own clock is wrong.  Thus, a security-aware
+   resolver which is part of a security-aware recursive name server will
+   need to pay careful attention to the DNSSEC "checking disabled" (CD)
+   bit [I-D.ietf-dnsext-dnssec-records].  This is in order to avoid
+   blocking valid signatures from getting through to other
+   security-aware resolvers which are clients of this recursive name
+   server.  See [I-D.ietf-dnsext-dnssec-protocol] for how a secure
+   recursive server handles queries with the CD bit set.
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 14]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+7.  Stub Resolver Considerations
+
+   Although not strictly required to do so by the protocol, most DNS
+   queries originate from stub resolvers.  Stub resolvers, by
+   definition, are minimal DNS resolvers which use recursive query mode
+   to offload most of the work of DNS resolution to a recursive name
+   server.  Given the widespread use of stub resolvers, the DNSSEC
+   architecture has to take stub resolvers into account, but the
+   security features needed in a stub resolver differ in some respects
+   from those needed in a full security-aware resolver.
+
+   Even a security-oblivious stub resolver may get some benefit from
+   DNSSEC if the recursive name servers it uses are security-aware, but
+   for the stub resolver to place any real reliance on DNSSEC services,
+   the stub resolver must trust both the recursive name servers in
+   question and the communication channels between itself and those name
+   servers.  The first of these issues is a local policy issue: in
+   essence, a security-oblivious stub resolver has no real choice but to
+   place itself at the mercy of the recursive name servers that it uses,
+   since it does not perform DNSSEC validity checks on its own.  The
+   second issue requires some kind of channel security mechanism; proper
+   use of DNS transaction authentication mechanisms such as SIG(0) or
+   TSIG would suffice, as would appropriate use of IPsec, and particular
+   implementations may have other choices available, such as operating
+   system specific interprocess communication mechanisms.
+   Confidentiality is not needed for this channel, but data integrity
+   and message authentication are.
+
+   A security-aware stub resolver that does trust both its recursive
+   name servers and its communication channel to them may choose to
+   examine the setting of the AD bit in the message header of the
+   response messages it receives.  The stub resolver can use this flag
+   bit as a hint to find out whether the recursive name server was able
+   to validate signatures for all of the data in the Answer and
+   Authority sections of the response.
+
+   There is one more step that a security-aware stub resolver can take
+   if, for whatever reason, it is not able to establish a useful trust
+   relationship with the recursive name servers which it uses: it can
+   perform its own signature validation, by setting the Checking
+   Disabled (CD) bit in its query messages.  A validating stub resolver
+   is thus able to treat the DNSSEC signatures as a trust relationship
+   between the zone administrator and the stub resolver itself.
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 15]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+8.  Zone Considerations
+
+   There are several differences between signed and unsigned zones.  A
+   signed zone will contain additional security-related records (RRSIG,
+   DNSKEY, DS and NSEC records).  RRSIG and NSEC records may be
+   generated by a signing process prior to serving the zone.  The RRSIG
+   records that accompany zone data have defined inception and
+   expiration times, which establish a validity period for the
+   signatures and the zone data the signatures cover.
+
+8.1  TTL values vs. RRSIG validity period
+
+   It is important to note the distinction between a RRset's TTL value
+   and the signature validity period specified by the RRSIG RR covering
+   that RRset.  DNSSEC does not change the definition or function of the
+   TTL value, which is intended to maintain database coherency in
+   caches.  A caching resolver purges RRsets from its cache no later
+   than the end of the time period specified by the TTL fields of those
+   RRsets, regardless of whether or not the resolver is security-aware.
+
+   The inception and expiration fields in the RRSIG RR
+   [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time
+   period during which the signature can be used to validate the covered
+   RRset.  The signatures associated with signed zone data are only
+   valid for the time period specified by these fields in the RRSIG RRs
+   in question.  TTL values cannot extend the validity period of signed
+   RRsets in a resolver's cache, but the resolver may use the time
+   remaining before expiration of the signature validity period of a
+   signed RRset as an upper bound for the TTL of the signed RRset and
+   its associated RRSIG RR in the resolver's cache.
+
+8.2  New Temporal Dependency Issues for Zones
+
+   Information in a signed zone has a temporal dependency which did not
+   exist in the original DNS protocol.  A signed zone requires regular
+   maintenance to ensure that each RRset in the zone has a current valid
+   RRSIG RR.  The signature validity period of an RRSIG RR is an
+   interval during which the signature for one particular signed RRset
+   can be considered valid, and the signatures of different RRsets in a
+   zone may expire at different times.  Re-signing one or more RRsets in
+   a zone will change one or more RRSIG RRs, which in turn will require
+   incrementing the zone's SOA serial number to indicate that a zone
+   change has occurred and re-signing the SOA RRset itself.  Thus,
+   re-signing any RRset in a zone may also trigger DNS NOTIFY messages
+   and zone transfers operations.
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 16]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+9.  Name Server Considerations
+
+   A security-aware name server should include the appropriate DNSSEC
+   records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from
+   resolvers which have signaled their willingness to receive such
+   records via use of the DO bit in the EDNS header, subject to message
+   size limitations.  Since inclusion of these DNSSEC RRs could easily
+   cause UDP message truncation and fallback to TCP, a security-aware
+   name server must also support the EDNS "sender's UDP payload"
+   mechanism.
+
+   If possible, the private half of each DNSSEC key pair should be kept
+   offline, but this will not be possible for a zone for which DNS
+   dynamic update has been enabled.  In the dynamic update case, the
+   primary master server for the zone will have to re-sign the zone when
+   updated, so the private key corresponding to the zone signing key
+   will have to be kept online.  This is an example of a situation where
+   the ability to separate the zone's DNSKEY RRset into zone signing
+   key(s) and key signing key(s) may be useful, since the key signing
+   key(s) in such a case can still be kept offline and may have a longer
+   useful lifetime than the zone signing key(s).
+
+   DNSSEC, by itself, is not enough to protect the integrity of an
+   entire zone during zone transfer operations, since even a signed zone
+   contains some unsigned, nonauthoritative data if the zone has any
+   children.  Therefore, zone maintenance operations will require some
+   additional mechanisms (most likely some form of channel security,
+   such as TSIG, SIG(0), or IPsec).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 17]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+10.  DNS Security Document Family
+
+   The DNSSEC document set can be partitioned into several main groups,
+   under the larger umbrella of the DNS base protocol documents.
+
+   The "DNSSEC protocol document set" refers to the three documents
+   which form the core of the DNS security extensions:
+   1.  DNS Security Introduction and Requirements (this document)
+   2.  Resource Records for DNS Security Extensions
+       [I-D.ietf-dnsext-dnssec-records]
+   3.  Protocol Modifications for the DNS Security Extensions
+       [I-D.ietf-dnsext-dnssec-protocol]
+
+   Additionally, any document that would add to, or change the core DNS
+   Security extensions would fall into this category.  This includes any
+   future work on the communication between security-aware stub
+   resolvers and upstream security-aware recursive name servers.
+
+   The "Digital Signature Algorithm Specification" document set refers
+   to the group of documents that describe how specific digital
+   signature algorithms should be implemented to fit the DNSSEC resource
+   record format.  Each document in this set deals with a specific
+   digital signature algorithm.
+
+   The "Transaction Authentication Protocol" document set refers to the
+   group of documents that deal with DNS message authentication,
+   including secret key establishment and verification.  While not
+   strictly part of the DNSSEC specification as defined in this set of
+   documents, this group is noted because of its relationship to DNSSEC.
+
+   The final document set, "New Security Uses", refers to documents that
+   seek to use proposed DNS Security extensions for other security
+   related purposes.  DNSSEC does not provide any direct security for
+   these new uses, but may be used to support them.  Documents that fall
+   in this category include the use of DNS in the storage and
+   distribution of certificates [RFC2538].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 18]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+11.  IANA Considerations
+
+   This overview document introduces no new IANA considerations.  Please
+   see [I-D.ietf-dnsext-dnssec-records] for a complete review of the
+   IANA considerations introduced by DNSSEC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 19]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+12.  Security Considerations
+
+   This document introduces the DNS security extensions and describes
+   the document set that contains the new security records and DNS
+   protocol modifications.  The extensions provide data origin
+   authentication and data integrity using digital signatures over
+   resource record sets.This document discusses the capabilities and
+   limitations of these extensions.
+
+   In order for a security-aware resolver to validate a DNS response,
+   all zones along the path from the trusted starting point to the zone
+   containing the response zones must be signed, and all name servers
+   and resolvers involved in the resolution process must be
+   security-aware, as defined in this document set.  A security-aware
+   resolver cannot verify responses originating from an unsigned zone,
+   from a zone not served by a security-aware name server, or for any
+   DNS data which the resolver is only able to obtain through a
+   recursive name server which is not security-aware.  If there is a
+   break in the authentication chain such that a security-aware resolver
+   cannot obtain and validate the authentication keys it needs, then the
+   security-aware resolver cannot validate the affected DNS data.
+
+   This document briefly discusses other methods of adding security to a
+   DNS query, such as using a channel secured by IPsec or using a DNS
+   transaction authentication mechanism, but transaction security is not
+   part of DNSSEC per se.
+
+   A non-validating security-aware stub resolver, by definition, does
+   not perform DNSSEC signature validation on its own, and thus is
+   vulnerable both to attacks on (and by) the security-aware recursive
+   name servers which perform these checks on its behalf and also to
+   attacks on its communication with those security-aware recursive name
+   servers.  Non-validating security-aware stub resolvers should use
+   some form of channel security to defend against the latter threat.
+   The only known defense against the former threat would be for the
+   security-aware stub resolver to perform its own signature validation,
+   at which point, again by definition, it would no longer be a
+   non-validating security-aware stub resolver.
+
+   DNSSEC does not protect against denial of service attacks.  DNSSEC
+   makes DNS vulnerable to a new class of denial of service attacks
+   based on cryptographic operations against security-aware resolvers
+   and security-aware name servers, since an attacker can attempt to use
+   DNSSEC mechanisms to consume a victim's resources.  This class of
+   attacks takes at least two forms.  An attacker may be able to consume
+   resources in a security-aware resolver's signature validation code by
+   tampering with RRSIG RRs in response messages or by constructing
+   needlessly complex signature chains.  An attacker may also be able to
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 20]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+   consume resources in a security-aware name server which supports DNS
+   dynamic update, by sending a stream of update messages that force the
+   security-aware name server to re-sign some RRsets in the zone more
+   frequently than would otherwise be necessary.
+
+   DNSSEC does not provide confidentiality, due to a deliberate design
+   choice.
+
+   DNSSEC introduces the ability for a hostile party to enumerate all
+   the names in a zone by following the NSEC chain.  NSEC RRs assert
+   which names do not exist in a zone by linking from existing name to
+   existing name along a canonical ordering of all the names within a
+   zone.  Thus, an attacker can query these NSEC RRs in sequence to
+   obtain all the names in a zone.  While not an attack on the DNS
+   itself, this could allow an attacker to map network hosts or other
+   resources by enumerating the contents of a zone.
+
+   DNSSEC introduces significant additional complexity to the DNS, and
+   thus introduces many new opportunities for implementation bugs and
+   misconfigured zones.  In particular, enabling DNSSEC signature
+   validation in a resolver may cause entire legitimate zones to become
+   effectively unreachable due to DNSSEC configuration errors or bugs.
+
+   DNSSEC does not protect against tampering with unsigned zone data.
+   Non-authoritative data at zone cuts (glue and NS RRs in the parent
+   zone) are not signed.  This does not pose a problem when validating
+   the authentication chain, but does mean that the non-authoritative
+   data itself is vulnerable to tampering during zone transfer
+   operations.  Thus, while DNSSEC can provide data origin
+   authentication and data integrity for RRsets, it cannot do so for
+   zones, and other mechanisms must be used to protect zone transfer
+   operations.
+
+   Please see [I-D.ietf-dnsext-dnssec-records] and
+   [I-D.ietf-dnsext-dnssec-protocol] for additional security
+   considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 21]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+13.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group.  While explicitly listing everyone
+   who has contributed during the decade during which DNSSEC has been
+   under development would be an impossible task, the editors would
+   particularly like to thank the following people for their
+   contributions to and comments on this document set: Jaap Akkerhuis,
+   Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
+   David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
+   Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
+   Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip
+   Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
+   Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
+   Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
+   Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
+   Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
+   Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid,
+   Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob
+   Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and
+   Suzanne Woolf.
+
+   No doubt the above list is incomplete.  We apologize to anyone we
+   left out.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 22]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+14.  References
+
+14.1  Normative References
+
+   [I-D.ietf-dnsext-dnssec-protocol]
+              Arends, R., Austein, R., Larson, M., Massey, D. and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
+              progress), May 2004.
+
+   [I-D.ietf-dnsext-dnssec-records]
+              Arends, R., Austein, R., Larson, M., Massey, D. and S.
+              Rose, "Resource Records for DNS Security Extensions",
+              draft-ietf-dnsext-dnssec-records-08 (work in progress),
+              May 2004.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226, December 2001.
+
+   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
+              Resource Record (RR)", RFC 3445, December 2002.
+
+14.2  Informative References
+
+   [I-D.ietf-dnsext-dns-threats]
+              Atkins, D. and R. Austein, "Threat Analysis Of The Domain
+              Name System", draft-ietf-dnsext-dns-threats-07 (work in
+              progress), April 2004.
+
+   [I-D.ietf-dnsext-nsec-rdata]
+              Schlyter, J., "DNSSEC NSEC RDATA Format",
+              draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
+              2004.
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 23]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+              April 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2538]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in
+              the Domain Name System (DNS)", RFC 2538, March 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
+              SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
+              Signing Authority", RFC 3008, November 2000.
+
+   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
+              Status", RFC 3090, March 2001.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+              Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer", RFC 3755, April 2004.
+
+   [RFC3757]  Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
+              Entry Point Flag", RFC 3757, April 2004.
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 24]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Drienerlolaan 5
+   7522 NB  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   USC Information Sciences Institute
+   3811 N. Fairfax Drive
+   Arlington, VA  22203
+   USA
+
+   EMail: masseyd@isi.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 25]
+
+Internet-Draft    DNSSEC Introduction and Requirements         July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 26]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
index a6f628e3..5728b35c 100644
--- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt
+++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
@@ -1,3249 +1,3193 @@
-

-

-DNS Extensions                                                 R. Arends

-Internet-Draft                                      Telematica Instituut

-Expires: November 15, 2004                                     M. Larson

-                                                                VeriSign

-                                                              R. Austein

-                                                                     ISC

-                                                               D. Massey

-                                                                 USC/ISI

-                                                                 S. Rose

-                                                                    NIST

-                                                            May 17, 2004

-

-

-         Protocol Modifications for the DNS Security Extensions

-                  draft-ietf-dnsext-dnssec-protocol-06

-

-Status of this Memo

-

-   This document is an Internet-Draft and is in full conformance with

-   all provisions of Section 10 of RFC2026.

-

-   Internet-Drafts are working documents of the Internet Engineering

-   Task Force (IETF), its areas, and its working groups. Note that other

-   groups may also distribute working documents as Internet-Drafts.

-

-   Internet-Drafts are draft documents valid for a maximum of six months

-   and may be updated, replaced, or obsoleted by other documents at any

-   time. It is inappropriate to use Internet-Drafts as reference

-   material or to cite them other than as "work in progress."

-

-   The list of current Internet-Drafts can be accessed at http://

-   www.ietf.org/ietf/1id-abstracts.txt.

-

-   The list of Internet-Draft Shadow Directories can be accessed at

-   http://www.ietf.org/shadow.html.

-

-   This Internet-Draft will expire on November 15, 2004.

-

-Copyright Notice

-

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

-

-Abstract

-

-   This document is part of a family of documents which describe the DNS

-   Security Extensions (DNSSEC).  The DNS Security Extensions are a

-   collection of new resource records and protocol modifications which

-   add data origin authentication and data integrity to the DNS.  This

-   document describes the DNSSEC protocol modifications.  This document

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 1]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   defines the concept of a signed zone, along with the requirements for

-   serving and resolving using DNSSEC.  These techniques allow a

-   security-aware resolver to authenticate both DNS resource records and

-   authoritative DNS error indications.

-

-   This document obsoletes RFC 2535 and incorporates changes from all

-   updates to RFC 2535.

-

-Table of Contents

-

-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

-     1.1   Background and Related Documents . . . . . . . . . . . . .  4

-     1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4

-     1.3   Editors' Notes . . . . . . . . . . . . . . . . . . . . . .  4

-       1.3.1   Open Technical Issues  . . . . . . . . . . . . . . . .  4

-       1.3.2   Technical Changes or Corrections . . . . . . . . . . .  4

-       1.3.3   Typos and Minor Corrections  . . . . . . . . . . . . .  5

-   2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  6

-     2.1   Including DNSKEY RRs in a Zone . . . . . . . . . . . . . .  6

-     2.2   Including RRSIG RRs in a Zone  . . . . . . . . . . . . . .  6

-     2.3   Including NSEC RRs in a Zone . . . . . . . . . . . . . . .  7

-     2.4   Including DS RRs in a Zone . . . . . . . . . . . . . . . .  8

-     2.5   Changes to the CNAME Resource Record.  . . . . . . . . . .  8

-     2.6   Example of a Secure Zone . . . . . . . . . . . . . . . . .  9

-   3.  Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

-     3.1   Authoritative Name Servers . . . . . . . . . . . . . . . . 11

-       3.1.1   Including RRSIG RRs in a Response  . . . . . . . . . . 11

-       3.1.2   Including DNSKEY RRs In a Response . . . . . . . . . . 12

-       3.1.3   Including NSEC RRs In a Response . . . . . . . . . . . 12

-       3.1.4   Including DS RRs In a Response . . . . . . . . . . . . 15

-       3.1.5   Responding to Queries for Type AXFR or IXFR  . . . . . 16

-       3.1.6   The AD and CD Bits in an Authoritative Response  . . . 17

-     3.2   Recursive Name Servers . . . . . . . . . . . . . . . . . . 17

-       3.2.1   The DO bit . . . . . . . . . . . . . . . . . . . . . . 18

-       3.2.2   The CD bit . . . . . . . . . . . . . . . . . . . . . . 18

-       3.2.3   The AD bit . . . . . . . . . . . . . . . . . . . . . . 19

-     3.3   Example DNSSEC Responses . . . . . . . . . . . . . . . . . 19

-   4.  Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . . 20

-     4.1   EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 20

-     4.2   Signature Verification Support . . . . . . . . . . . . . . 20

-     4.3   Determining Security Status of Data  . . . . . . . . . . . 21

-     4.4   Configured Trust Anchors . . . . . . . . . . . . . . . . . 21

-     4.5   Response Caching . . . . . . . . . . . . . . . . . . . . . 22

-     4.6   Handling of the CD and AD bits . . . . . . . . . . . . . . 22

-     4.7   Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22

-     4.8   Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23

-     4.9   Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23

-       4.9.1   Handling of the DO Bit . . . . . . . . . . . . . . . . 24

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 2]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-       4.9.2   Handling of the CD Bit . . . . . . . . . . . . . . . . 24

-       4.9.3   Handling of the AD Bit . . . . . . . . . . . . . . . . 24

-   5.  Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25

-     5.1   Special Considerations for Islands of Security . . . . . . 26

-     5.2   Authenticating Referrals . . . . . . . . . . . . . . . . . 26

-     5.3   Authenticating an RRset Using an RRSIG RR  . . . . . . . . 27

-       5.3.1   Checking the RRSIG RR Validity . . . . . . . . . . . . 28

-       5.3.2   Reconstructing the Signed Data . . . . . . . . . . . . 28

-       5.3.3   Checking the Signature . . . . . . . . . . . . . . . . 30

-       5.3.4   Authenticating A Wildcard Expanded RRset Positive

-               Response . . . . . . . . . . . . . . . . . . . . . . . 31

-     5.4   Authenticated Denial of Existence  . . . . . . . . . . . . 31

-     5.5   Resolver Behavior When Signatures Do Not Validate  . . . . 32

-     5.6   Authentication Example . . . . . . . . . . . . . . . . . . 32

-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33

-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34

-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35

-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 36

-   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 36

-   9.2   Informative References . . . . . . . . . . . . . . . . . . . 36

-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37

-   A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 39

-   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 45

-     B.1   Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45

-     B.2   Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46

-     B.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . 47

-     B.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . 48

-     B.5   Referral to Unsigned Zone  . . . . . . . . . . . . . . . . 49

-     B.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50

-     B.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51

-     B.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . 52

-   C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 54

-     C.1   Authenticating An Answer . . . . . . . . . . . . . . . . . 54

-       C.1.1   Authenticating the example DNSKEY RR . . . . . . . . . 54

-     C.2   Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55

-     C.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . 55

-     C.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . 55

-     C.5   Referral to Unsigned Zone  . . . . . . . . . . . . . . . . 55

-     C.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56

-     C.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56

-     C.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . 56

-       Intellectual Property and Copyright Statements . . . . . . . . 57

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 3]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-1.  Introduction

-

-   The DNS Security Extensions (DNSSEC) are a collection of new resource

-   records and protocol modifications which add data origin

-   authentication and data integrity to the DNS. This document defines

-   the DNSSEC protocol modifications. Section 2 of this document defines

-   the concept of a signed zone and lists the requirements for zone

-   signing. Section 3 describes the modifications to authoritative name

-   server behavior necessary to handle signed zones. Section 4 describes

-   the behavior of entities which include security-aware resolver

-   functions. Finally, Section 5 defines how to use DNSSEC RRs to

-   authenticate a response.

-

-1.1  Background and Related Documents

-

-   The reader is assumed to be familiar with the basic DNS concepts

-   described in [RFC1034] and [RFC1035].

-

-   This document is part of a family of documents that define DNSSEC.

-   An introduction to DNSSEC and definition of common terms can be found

-   in [I-D.ietf-dnsext-dnssec-intro].  A definition of the DNSSEC

-   resource records can be found in [I-D.ietf-dnsext-dnssec-records].

-

-1.2  Reserved Words

-

-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this

-   document are to be interpreted as described in RFC 2119. [RFC2119].

-

-1.3  Editors' Notes

-

-1.3.1  Open Technical Issues

-

-1.3.2  Technical Changes or Corrections

-

-   Please report technical corrections to dnssec-editors@east.isi.edu.

-   To assist the editors, please indicate the text in error and point

-   out the RFC that defines the correct behavior.  For a technical

-   change where no RFC that defines the correct behavior, or if there's

-   more than one applicable RFC and the definitions conflict, please

-   post the issue to namedroppers.

-

-   An example correction to dnssec-editors might be: Page X says

-   "DNSSEC RRs SHOULD be automatically returned in responses."  This was

-   true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the

-   DNSSEC RR types MUST NOT be included in responses unless the resolver

-   indicated support for DNSSEC.

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 4]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-1.3.3  Typos and Minor Corrections

-

-   Please report any typos corrections to dnssec-editors@east.isi.edu.

-   To assist the editors, please provide enough context for us to find

-   the incorrect text quickly.

-

-   An example message to dnssec-editors might be: page X says "the

-   DNSSEC standard has been in development for over 1 years".   It

-   should read "over 10 years".

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 5]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-2.  Zone Signing

-

-   DNSSEC introduces the concept of signed zones.  A signed zone

-   includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to

-   the rules specified in Section 2.1, Section 2.2, Section 2.3 and

-   Section 2.4, respectively.  A zone that does not include these

-   records according to the rules in this section is an unsigned zone.

-

-   DNSSEC requires a change to the definition of the CNAME resource

-   record [RFC1035].  Section 2.5 changes the CNAME RR to allow RRSIG

-   and NSEC RRs to appear at the same owner name as a CNAME RR.

-

-2.1  Including DNSKEY RRs in a Zone

-

-   To sign a zone, the zone's administrator generates one or more

-   public/private key pairs and uses the private key(s) to sign

-   authoritative RRsets in the zone.  For each private key used to

-   create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with

-   the public component stored in the zone. A zone key DNSKEY RR MUST

-   have the Zone Key bit of the flags RDATA field set to one -- see

-   Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records].  Public keys

-   associated with other DNS operations MAY be stored in DNSKEY RRs that

-   are not marked as zone keys but MUST NOT be used to verify RRSIGs.

-

-   If the zone is delegated and does not wish to act as an island of

-   security, the zone MUST have at least one DNSKEY RR at the apex to

-   act as a secure entry point into the zone.  This DNSKEY would then be

-   used to generate a DS RR at the delegating parent (see

-   [I-D.ietf-dnsext-dnssec-records]).

-

-   DNSKEY RRs MUST NOT appear at delegation points.

-

-2.2  Including RRSIG RRs in a Zone

-

-   For each authoritative RRset in a signed zone, there MUST be at least

-   one RRSIG record that meets all of the following requirements:

-   o  The RRSIG owner name is equal to the RRset owner name;

-   o  The RRSIG class is equal to the RRset class;

-   o  The RRSIG Type Covered field is equal to the RRset type;

-   o  The RRSIG Original TTL field is equal to the TTL of the RRset;

-   o  The RRSIG RR's TTL is equal to the TTL of the RRset;

-   o  The RRSIG Labels field is equal to the number of labels in the

-      RRset owner name, not counting the null root label and not

-      counting the leftmost label if it is a wildcard;

-   o  The RRSIG Signer's Name field is equal to the name of the zone

-      containing the RRset; and

-   o  The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a

-      zone key DNSKEY record at the zone apex.

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 6]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   The process for constructing the RRSIG RR for a given RRset is

-   described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have

-   multiple RRSIG RRs associated with it.

-

-   An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR

-   would add no value and would create an infinite loop in the signing

-   process.

-

-   The NS RRset that appears at the zone apex name MUST be signed, but

-   the NS RRsets that appear at delegation points (that is, the NS

-   RRsets in the parent zone that delegate the name to the child zone's

-   name servers) MUST NOT be signed. Glue address RRsets associated with

-   delegations MUST NOT be signed.

-

-   There MUST be an RRSIG for each RRset using at least one DNSKEY of

-   each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset

-   itself MUST be signed by each algorithm appearing in the DS RRset

-   located at the delegating parent (if any).

-

-2.3  Including NSEC RRs in a Zone

-

-   Each owner name in the zone which has authoritative data or a

-   delegation point NS RRset MUST have an NSEC resource record. The

-   process for constructing the NSEC RR for a given name is described in

-   [I-D.ietf-dnsext-dnssec-records].

-

-   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL

-   value field in the zone SOA RR.

-

-   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only

-   RRset at any particular owner name.  That is, the signing process

-   MUST NOT create NSEC or RRSIG RRs for owner names nodes which were

-   not the owner name of any RRset before the zone was signed.  The main

-   reasons for this are a desire for namespace consistency between

-   signed and unsigned versions of the same zone and a desire to reduce

-   the risk of response inconsistency in security oblivious recursive

-   name servers.

-

-   The type bitmap of every NSEC resource record in a signed zone MUST

-   indicate the presence of both the NSEC record itself and its

-   corresponding RRSIG record.

-

-   The difference between the set of owner names that require RRSIG

-   records and the set of owner names that require NSEC records is

-   subtle and worth highlighting.  RRSIG records are present at the

-   owner names of all authoritative RRsets.  NSEC records are present at

-   the owner names of all names for which the signed zone is

-   authoritative and also at the owner names of delegations from the

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 7]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   signed zone to its children.  Neither NSEC nor RRSIG records are

-   present (in the parent zone) at the owner names of glue address

-   RRsets.  Note, however, that this distinction is for the most part is

-   only visible during the zone signing process, because NSEC RRsets are

-   authoritative data, and are therefore signed, thus any owner name

-   which has an NSEC RRset will have RRSIG RRs as well in the signed

-   zone.

-

-   The bitmap for the NSEC RR at a delegation point requires special

-   attention.  Bits corresponding to the delegation NS RRset and the RR

-   types for which the parent zone has authoritative data MUST be set to

-   1; bits corresponding to any non-NS RRset for which the parent is not

-   authoritative MUST be set to 0.

-

-2.4  Including DS RRs in a Zone

-

-   The DS resource record establishes authentication chains between DNS

-   zones.  A DS RRset SHOULD be present at a delegation point when the

-   child zone is signed.  The DS RRset MAY contain multiple records,

-   each referencing a public key in the child zone used to verify the

-   RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS

-   RRsets MUST NOT appear at a zone's apex.

-

-   A DS RR SHOULD point to a DNSKEY RR which is present in the child's

-   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed

-   by the corresponding private key.

-

-   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset

-   (i.e., the NS RRset from the same zone containing the DS RRset).

-

-   Construction of a DS RR requires knowledge of the corresponding

-   DNSKEY RR in the child zone, which implies communication between the

-   child and parent zones.  This communication is an operational matter

-   not covered by this document.

-

-2.5  Changes to the CNAME Resource Record.

-

-   If a CNAME RRset is present at a name in a signed zone, appropriate

-   RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that

-   name for secure dynamic update purposes is also allowed.  Other types

-   MUST NOT be present at that name.

-

-   This is a modification to the original CNAME definition given in

-   [RFC1034].  The original definition of the CNAME RR did not allow any

-   other types to coexist with a CNAME record, but a signed zone

-   requires NSEC and RRSIG RRs for every authoritative name.  To resolve

-   this conflict, this specification modifies the definition of the

-   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 8]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-2.6  Example of a Secure Zone

-

-   Appendix A shows a complete example of a small signed zone.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 9]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-3.  Serving

-

-   This section describes the behavior of entities that include

-   security-aware name server functions.  In many cases such functions

-   will be part of a security-aware recursive name server, but a

-   security-aware authoritative name server has some of the same

-   requirements.  Functions specific to security-aware recursive name

-   servers are described in Section 3.2; functions specific to

-   authoritative servers are described in Section 3.1.

-

-   The terms "SNAME", "SCLASS", and "STYPE" in the following discussion

-   are as used in [RFC1034].

-

-   A security-aware name server MUST support the EDNS0 [RFC2671] message

-   size extension, MUST support a message size of at least 1220 octets,

-   and SHOULD support a message size of 4000 octets [RFC3226].

-

-   A security-aware name server that receives a DNS query that does not

-   include the EDNS OPT pseudo-RR or that has the DO bit set to zero

-   MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other

-   RRset, and MUST NOT perform any of the additional processing

-   described below.  Since the DS RR type has the peculiar property of

-   only existing in the parent zone at delegation points, DS RRs always

-   require some special processing, as described in Section 3.1.4.1.

-

-   Security aware name servers that receive queries for security RR

-   types which match the content of more than one zone that it serves

-   (e.g. NSEC and RRSIG RRs above and below a delegation point where the

-   server is authoritative for both zones) are encouraged to behave

-   self-consistently.  The name server MAY return one of the following:

-   o  The above-delegation RRsets

-   o  The below-delegation RRsets

-   o  Both above and below-delegation RRsets

-   o  Empty answer section (i.e. no records)

-   o  Some other response

-   o  An error

-   As long as the response is always consistent for each query to the

-   name server.

-

-   DNSSEC allocates two new bits in the DNS message header: the CD

-   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit

-   is controlled by resolvers; a security-aware name server MUST copy

-   the CD bit from a query into the corresponding response.  The AD bit

-   is controlled by name servers; a security-aware name server MUST

-   ignore the setting of the AD bit in queries.  See Section 3.1.6,

-   Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details

-   on the behavior of these bits.

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 10]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   A security aware name server which synthesizes CNAME RRs from DNAME

-   RRs as described in [RFC2672] SHOULD NOT generate signatures for the

-   synthesized CNAME RRs.

-

-3.1  Authoritative Name Servers

-

-   Upon receiving a relevant query that has the EDNS [RFC2671] OPT

-   pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative

-   name server for a signed zone MUST include additional RRSIG, NSEC,

-   and DS RRs according to the following rules:

-   o  RRSIG RRs that can be used to authenticate a response MUST be

-      included in the response according to the rules in Section 3.1.1;

-   o  NSEC RRs that can be used to provide authenticated denial of

-      existence MUST be included in the response automatically according

-      to the rules in Section 3.1.3;

-   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST

-      be included in referrals automatically according to the rules in

-      Section 3.1.4.

-

-   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5

-   discusses zone transfer requirements.

-

-3.1.1  Including RRSIG RRs in a Response

-

-   When responding to a query that has the DO bit set to one, a

-   security-aware authoritative name server SHOULD attempt to send RRSIG

-   RRs that a security-aware resolver can use to authenticate the RRsets

-   in the response.  A name server SHOULD make every attempt to keep the

-   RRset and its associated RRSIG(s) together in a response.  Inclusion

-   of RRSIG RRs in a response is subject to the following rules:

-   o  When placing a signed RRset in the Answer section, the name server

-      MUST also place its RRSIG RRs in the Answer section.  The RRSIG

-      RRs have a higher priority for inclusion than any other RRsets

-      that may need to be included.  If space does not permit inclusion

-      of these RRSIG RRs, the name server MUST set the TC bit.

-   o  When placing a signed RRset in the Authority section, the name

-      server MUST also place its RRSIG RRs in the Authority section.

-      The RRSIG RRs have a higher priority for inclusion than any other

-      RRsets that may need to be included.  If space does not permit

-      inclusion of these RRSIG RRs, the name server MUST set the TC bit.

-   o  When placing a signed RRset in the Additional section, the name

-      server MUST also place its RRSIG RRs in the Additional section.

-      If space does not permit inclusion of both the RRset and its

-      associated RRSIG RRs, the name server MAY drop the RRSIG RRs.  If

-      this happens, the name server MUST NOT set the TC bit solely

-      because these RRSIG RRs didn't fit.

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 11]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-3.1.2  Including DNSKEY RRs In a Response

-

-   When responding to a query that has the DO bit set to one and that

-   requests the SOA or NS RRs at the apex of a signed zone, a

-   security-aware authoritative name server for that zone MAY return the

-   zone apex DNSKEY RRset in the Additional section.  In this situation,

-   the DNSKEY RRset and associated RRSIG RRs have lower priority than

-   any other information that would be placed in the additional section.

-   The name server SHOULD NOT include the DNSKEY RRset unless there is

-   enough space in the response message for both the DNSKEY RRset and

-   its associated RRSIG RR(s). If there is not enough space to include

-   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST

-   NOT set the TC bit solely because these RRs didn't fit (see Section

-   3.1.1).

-

-3.1.3  Including NSEC RRs In a Response

-

-   When responding to a query that has the DO bit set to one, a

-   security-aware authoritative name server for a signed zone MUST

-   include NSEC RRs in each of the following cases:

-

-   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,

-      but does not contain any RRsets that exactly match <SNAME, SCLASS,

-      STYPE>.

-

-   Name Error: The zone does not contain any RRsets that match <SNAME,

-      SCLASS> either exactly or via wildcard name expansion.

-

-   Wildcard Answer: The zone does not contain any RRsets that exactly

-      match <SNAME, SCLASS> but does contain an RRset that matches

-      <SNAME, SCLASS, STYPE> via wildcard name expansion.

-

-   Wildcard No Data: The zone does not contain any RRsets that exactly

-      match <SNAME, SCLASS>, does contain one or more RRsets that match

-      <SNAME, SCLASS> via wildcard name expansion, but does not contain

-      any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name

-      expansion.

-

-   In each of these cases, the name server includes NSEC RRs in the

-   response to prove that an exact match for <SNAME, SCLASS, STYPE> was

-   not present in the zone and that the response that the name server is

-   returning is correct given the data that are in the zone.

-

-3.1.3.1  Including NSEC RRs: No Data Response

-

-   If the zone contains RRsets matching <SNAME, SCLASS> but contains no

-   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST

-   include the NSEC RR for <SNAME, SCLASS> along with its associated

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 12]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   RRSIG RR(s) in the Authority section of the response (see Section

-   3.1.1).  If space does not permit inclusion of the NSEC RR or its

-   associated RRSIG RR(s), the name server MUST set the TC bit (see

-   Section 3.1.1).

-

-   Since the search name exists, wildcard name expansion does not apply

-   to this query, and a single signed NSEC RR suffices to prove the

-   requested RR type does not exist.

-

-3.1.3.2  Including NSEC RRs: Name Error Response

-

-   If the zone does not contain any RRsets matching <SNAME, SCLASS>

-   either exactly or via wildcard name expansion, then the name server

-   MUST include the following NSEC RRs in the Authority section, along

-   with their associated RRSIG RRs:

-   o  An NSEC RR proving that there is no exact match for <SNAME,

-      SCLASS>; and

-   o  An NSEC RR proving that the zone contains no RRsets that would

-      match <SNAME, SCLASS> via wildcard name expansion.

-

-   In some cases a single NSEC RR may prove both of these points, in

-   that case the name server SHOULD only include the NSEC RR and its

-   RRSIG RR(s) once in the Authority section.

-

-   If space does not permit inclusion of these NSEC and RRSIG RRs, the

-   name server MUST set the TC bit (see Section 3.1.1).

-

-   The owner names of these NSEC and RRSIG RRs are not subject to

-   wildcard name expansion when these RRs are included in the Authority

-   section of the response.

-

-   Note that this form of response includes cases in which SNAME

-   corresponds to an empty non-terminal name within the zone (a name

-   which is not the owner name for any RRset but which is the parent

-   name of one or more RRsets).

-

-3.1.3.3  Including NSEC RRs: Wildcard Answer Response

-

-   If the zone does not contain any RRsets which exactly match <SNAME,

-   SCLASS> but does contain an RRset which matches <SNAME, SCLASS,

-   STYPE> via wildcard name expansion, the name server MUST include the

-   wildcard-expanded answer and the corresponding wildcard-expanded

-   RRSIG RRs in the Answer section, and MUST include in the Authority

-   section an NSEC RR and associated RRSIG RR(s) proving that the zone

-   does not contain a closer match for <SNAME, SCLASS>.  If space does

-   not permit inclusion of the answer, NSEC and RRSIG RRs, the name

-   server MUST set the TC bit (see Section 3.1.1).

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 13]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-3.1.3.4  Including NSEC RRs: Wildcard No Data Response

-

-   This case is a combination of the previous cases.  The zone does not

-   contain an exact match for <SNAME, SCLASS>, and while the zone does

-   contain RRsets which match <SNAME, SCLASS> via wildcard expansion,

-   none of those RRsets match STYPE.  The name server MUST include the

-   following NSEC RRs in the Authority section, along with their

-   associated RRSIG RRs:

-   o  An NSEC RR proving that there are no RRsets matching STYPE at the

-      wildcard owner name which matched <SNAME, SCLASS> via wildcard

-      expansion; and

-   o  An NSEC RR proving that there are no RRsets in the zone which

-      would have been a closer match for <SNAME, SCLASS>.

-

-   In some cases a single NSEC RR may prove both of these points, in

-   which case the name server SHOULD only include the NSEC RR and its

-   RRSIG RR(s) once in the Authority section.

-

-   The owner names of these NSEC and RRSIG RRs are not subject to

-   wildcard name expansion when these RRs are included in the Authority

-   section of the response.

-

-   If space does not permit inclusion of these NSEC and RRSIG RRs, the

-   name server MUST set the TC bit (see Section 3.1.1).

-

-3.1.3.5  Finding The Right NSEC RRs

-

-   As explained above, there are several situations in which a

-   security-aware authoritative name server needs to locate an NSEC RR

-   which proves that no RRsets matching a particular SNAME exist.

-   Locating such an NSEC RR within an authoritative zone is relatively

-   simple, at least in concept.  The following discussion assumes that

-   the name server is authoritative for the zone which would have held

-   the nonexistent RRsets matching SNAME.  The algorithm below is

-   written for clarity, not efficiency.

-

-   To find the NSEC which proves that no RRsets matching name N exist in

-   the zone Z which would have held them, construct sequence S

-   consisting of the owner names of every RRset in Z, sorted into

-   canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate

-   names.  Find the name M which would have immediately preceded N in S

-   if any RRsets with owner name N had existed.  M is the owner name of

-   the NSEC RR which proves that no RRsets exist with owner name N.

-

-   The algorithm for finding the NSEC RR which proves that a given name

-   is not covered by any applicable wildcard is similar, but requires an

-   extra step.  More precisely, the algorithm for finding the NSEC

-   proving that no RRsets exist with the applicable wildcard name is

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 14]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   precisely the same as the algorithm for finding the NSEC RR which

-   proves that RRsets with any other owner name do not exist: the part

-   that's missing is how to determine the name of the nonexistent

-   applicable wildcard.  In practice, this is easy, because the

-   authoritative name server has already checked for the presence of

-   precisely this wildcard name as part of step (1)(c) of the normal

-   lookup algorithm described in Section 4.3.2 of [RFC1034].

-

-3.1.4  Including DS RRs In a Response

-

-   When responding to a query which has the DO bit set to one, a

-   security-aware authoritative name server returning a referral

-   includes DNSSEC data along with the NS RRset.

-

-   If a DS RRset is present at the delegation point, the name server

-   MUST return both the DS RRset and its associated RRSIG RR(s) in the

-   Authority section along with the NS RRset.  The name server MUST

-   place the NS RRset before the DS RRset and its associated RRSIG

-   RR(s).

-

-   If no DS RRset is present at the delegation point, the name server

-   MUST return both the NSEC RR which proves that the DS RRset is not

-   present and the NSEC RR's associated RRSIG RR(s) along with the NS

-   RRset.  The name server MUST place the NS RRset before the NSEC RRset

-   and its associated RRSIG RR(s).

-

-   Including these DS, NSEC, and RRSIG RRs increases the size of

-   referral messages, and may cause some or all glue RRs to be omitted.

-   If space does not permit inclusion of the DS or NSEC RRset and

-   associated RRSIG RRs, the name server MUST set the TC bit (see

-   Section 3.1.1).

-

-3.1.4.1  Responding to Queries for DS RRs

-

-   The DS resource record type is unusual in that it appears only on the

-   parent zone's side of a zone cut.  For example, the DS RRset for the

-   delegation of "foo.example" is stored in the "example" zone rather

-   than in the "foo.example" zone.  This requires special processing

-   rules for both name servers and resolvers, since the name server for

-   the child zone is authoritative for the name at the zone cut by the

-   normal DNS rules but the child zone does not contain the DS RRset.

-

-   A security-aware resolver sends queries to the parent zone when

-   looking for a needed DS RR at a delegation point (see Section 4.2).

-   However, special rules are necessary to avoid confusing

-   security-oblivious resolvers which might become involved in

-   processing such a query (for example, in a network configuration that

-   forces a security-aware resolver to channel its queries through a

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 15]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   security-oblivious recursive name server).  The rest of this section

-   describes how a security-aware name server processes DS queries in

-   order to avoid this problem.

-

-   The need for special processing by a security-aware name server only

-   arises when all the following conditions are met:

-   o  the name server has received a query for the DS RRset at a zone

-      cut; and

-   o  the name server is authoritative for the child zone; and

-   o  the name server is not authoritative for the parent zone; and

-   o  the name server does not offer recursion.

-

-   In all other cases, the name server either has some way of obtaining

-   the DS RRset or could not have been expected to have the DS RRset

-   even by the pre-DNSSEC processing rules, so the name server can

-   return either the DS RRset or an error response according to the

-   normal processing rules.

-

-   If all of the above conditions are met, however, the name server is

-   authoritative for SNAME but cannot supply the requested RRset.  In

-   this case, the name server MUST return an authoritative "no data"

-   response showing that the DS RRset does not exist in the child zone's

-   apex.  See Appendix B.8 for an example of such a response.

-

-3.1.5  Responding to Queries for Type AXFR or IXFR

-

-   DNSSEC does not change the DNS zone transfer process.  A signed zone

-   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these

-   records have no special meaning with respect to a zone transfer

-   operation.

-

-   An authoritative name server is not required to verify that a zone is

-   properly signed before sending or accepting a zone transfer.

-   However, an authoritative name server MAY choose to reject the entire

-   zone transfer if the zone fails meets any of the signing requirements

-   described in Section 2.  The primary objective of a zone transfer is

-   to ensure that all authoritative name servers have identical copies

-   of the zone.  An authoritative name server that chooses to perform

-   its own zone validation MUST NOT selectively reject some RRs and

-   accept others.

-

-   DS RRsets appear only on the parental side of a zone cut and are

-   authoritative data in the parent zone.  As with any other

-   authoritative RRset, the DS RRset MUST be included in zone transfers

-   of the zone in which the RRset is authoritative data: in the case of

-   the DS RRset, this is the parent zone.

-

-   NSEC RRs appear in both the parent and child zones at a zone cut, and

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 16]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   are authoritative data in both the parent and child zones.  The

-   parental and child NSEC RRs at a zone cut are never identical to each

-   other, since the NSEC RR in the child zone's apex will always

-   indicate the presence of the child zone's SOA RR while the parental

-   NSEC RR at the zone cut will never indicate the presence of an SOA

-   RR.  As with any other authoritative RRs, NSEC RRs MUST be included

-   in zone transfers of the zone in which they are authoritative data:

-   the parental NSEC RR at a zone cut MUST be included zone transfers of

-   the parent zone, while the NSEC at the zone apex of the child zone

-   MUST be included in zone transfers of the child zone.

-

-   RRSIG RRs appear in both the parent and child zones at a zone cut,

-   and are authoritative in whichever zone contains the authoritative

-   RRset for which the RRSIG RR provides the signature.  That is, the

-   RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be

-   authoritative in the parent zone, while the RRSIG for any RRset in

-   the child zone's apex will be authoritative in the child zone. As

-   with any other authoritative RRs, RRSIG RRs MUST be included in zone

-   transfers of the zone in which they are authoritative data.

-

-3.1.6  The AD and CD Bits in an Authoritative Response

-

-   The CD and AD bits are designed for use in communication between

-   security-aware resolvers and security-aware recursive name servers.

-   These bits are for the most part not relevant to query processing by

-   security-aware authoritative name servers.

-

-   A security-aware name server does not perform signature validation

-   for authoritative data during query processing even when the CD bit

-   is set to zero.  A security-aware name server SHOULD clear the CD bit

-   when composing an authoritative response.

-

-   A security-aware name server MUST NOT set the AD bit in a response

-   unless the name server considers all RRsets in the Answer and

-   Authority sections of the response to be authentic.  A security-aware

-   name server's local policy MAY consider data from an authoritative

-   zone to be authentic without further validation, but the name server

-   MUST NOT do so unless the name server obtained the authoritative zone

-   via secure means (such as a secure zone transfer mechanism), and MUST

-   NOT do so unless this behavior has been configured explicitly.

-

-   A security-aware name server which supports recursion MUST follow the

-   rules for the CD and AD bits given in Section 3.2 when generating a

-   response that involves data obtained via recursion.

-

-3.2  Recursive Name Servers

-

-   As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 17]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   recursive name server is an entity which acts in both the

-   security-aware name server and security-aware resolver roles. This

-   section uses the terms "name server side" and "resolver side" to

-   refer to the code within a security-aware recursive name server which

-   implements the security-aware name server role and the code which

-   implements the security-aware resolver role, respectively.

-

-   The resolver side follows the usual rules for caching and negative

-   caching which would apply to any security-aware resolver.

-

-3.2.1  The DO bit

-

-   The resolver side of a security-aware recursive name server MUST set

-   the DO bit when sending requests, regardless of the state of the DO

-   bit in the initiating request received by the name server side.  If

-   the DO bit in an initiating query is not set, the name server side

-   MUST strip any authenticating DNSSEC RRs from the response, but MUST

-   NOT strip any DNSSEC RR types that the initiating query explicitly

-   requested.

-

-3.2.2  The CD bit

-

-   The CD bit exists in order to allow a security-aware resolver to

-   disable signature validation in a security-aware name server's

-   processing of a particular query.

-

-   The name server side MUST copy the setting of the CD bit from a query

-   to the corresponding response.

-

-   The name server side of a security-aware recursive name server MUST

-   pass the sense of the CD bit to the resolver side along with the rest

-   of an initiating query, so that the resolver side will know whether

-   or not it is required to verify the response data it returns to the

-   name server side. If the CD bit is set to one, it indicates that the

-   originating resolver is willing to perform whatever authentication

-   its local policy requires, thus the resolver side of the recursive

-   name server need not perform authentication on the RRsets in the

-   response.  When the CD bit is set to one the recursive name server

-   SHOULD, if possible, return the requested data to the originating

-   resolver even if the recursive name server's local authentication

-   policy would reject the records in question. That is, by setting the

-   CD bit, the originating resolver has indicated that it takes

-   responsibility for performing its own authentication, and the

-   recursive name server should not interfere.

-

-   If the resolver side implements a BAD cache (see Section 4.7) and the

-   name server side receives a query which matches an entry in the

-   resolver side's BAD cache, the name server side's response depends on

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 18]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   the sense of the CD bit in the original query.  If the CD bit is set,

-   the name server side SHOULD return the data from the BAD cache; if

-   the CD bit is not set, the name server side MUST return RCODE 2

-   (server failure).

-

-   The intent of the above rule is to provide the raw data to clients

-   which are capable of performing their own signature verification

-   checks while protecting clients which depend on the resolver side of

-   a security-aware recursive name server to perform such checks.

-   Several of the possible reasons why signature validation might fail

-   involve conditions which may not apply equally to the recursive name

-   server and the client which invoked it: for example, the recursive

-   name server's clock may be set incorrectly, or the client may have

-   knowledge of a relevant island of security which the recursive name

-   server does not share.  In such cases, "protecting" a client which is

-   capable of performing its own signature validation from ever seeing

-   the "bad" data does not help the client.

-

-3.2.3  The AD bit

-

-   The name server side of a security-aware recursive name server MUST

-   NOT set the AD bit in a response unless the name server considers all

-   RRsets in the Answer and Authority sections of the response to be

-   authentic.  The name server side SHOULD set the AD bit if and only if

-   the resolver side considers all RRsets in the Answer section and any

-   relevant negative response RRs in the Authority section to be

-   authentic.  The resolver side MUST follow the procedure described in

-   Section 5 to determine whether the RRs in question are authentic.

-   However, for backwards compatibility, a recursive name server MAY set

-   the AD bit when a response includes unsigned CNAME RRs if those CNAME

-   RRs demonstrably could have been synthesized from an authentic DNAME

-   RR which is also included in the response according to the synthesis

-   rules described in [RFC2672].

-

-3.3  Example DNSSEC Responses

-

-   See Appendix B for example response packets.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 19]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-4.  Resolving

-

-   This section describes the behavior of entities that include

-   security-aware resolver functions.  In many cases such functions will

-   be part of a security-aware recursive name server, but a stand-alone

-   security-aware resolver has many of the same requirements.  Functions

-   specific to security-aware recursive name servers are described in

-   Section 3.2.

-

-4.1  EDNS Support

-

-   A security-aware resolver MUST include an EDNS [RFC2671] OPT

-   pseudo-RR with the DO [RFC3225] bit set to one when sending queries.

-

-   A security-aware resolver MUST support a message size of at least

-   1220 octets, SHOULD support a message size of 4000 octets, and MUST

-   advertise the supported message size using the "sender's UDP payload

-   size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST

-   handle fragmented UDP packets correctly regardless of whether any

-   such fragmented packets were received via IPv4 or IPv6.  Please see

-   [RFC3226] for discussion of these requirements.

-

-4.2  Signature Verification Support

-

-   A security-aware resolver MUST support the signature verification

-   mechanisms described in Section 5, and MUST apply them to every

-   received response except when:

-   o  The security-aware resolver is part of a security-aware recursive

-      name server, and the response is the result of recursion on behalf

-      of a query received with the CD bit set;

-   o  The response is the result of a query generated directly via some

-      form of application interface which instructed the security-aware

-      resolver not to perform validation for this query; or

-   o  Validation for this query has been disabled by local policy.

-

-   A security-aware resolver's support for signature verification MUST

-   include support for verification of wildcard owner names.

-

-   Security aware resolvers MAY query for missing security RRs in an

-   attempt to perform validation; implementations that choose to do so

-   must be aware of the fact that the answers received may not be

-   sufficient to validate the original response.

-

-   When attempting to retrieve missing NSEC RRs which reside on the

-   parental side at a zone cut, a security-aware iterative-mode resolver

-   MUST query the name servers for the parent zone, not the child zone.

-

-   When attempting to retrieve a missing DS, a security-aware

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 20]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   iterative-mode resolver MUST query the name servers for the parent

-   zone, not the child zone.  As explained in Section 3.1.4.1,

-   security-aware name servers need to apply special processing rules to

-   handle the DS RR, and in some situations the resolver may also need

-   to apply special rules to locate the name servers for the parent zone

-   if the resolver does not already have the parent's NS RRset.  To

-   locate the parent NS RRset, the resolver can start with the

-   delegation name, strip off the leftmost label, and query for an NS

-   RRset by that name; if no NS RRset is present at that name, the

-   resolver then strips of the leftmost remaining label and retries the

-   query for that name, repeating this process of walking up the tree

-   until it either finds the NS RRset or runs out of labels.

-

-4.3  Determining Security Status of Data

-

-   A security-aware resolver MUST be able to determine whether or not it

-   should expect a particular RRset to be signed.  More precisely, a

-   security-aware resolver must be able to distinguish between four

-   cases:

-

-   Secure: An RRset for which the resolver is able to build a chain of

-      signed DNSKEY and DS RRs from a trusted security anchor to the

-      RRset.  In this case, the RRset should be signed, and is subject

-      to signature validation as described above.

-

-   Insecure: An RRset for which the resolver knows that it has no chain

-      of signed DNSKEY and DS RRs from any trusted starting point to the

-      RRset.  This can occur when the target RRset lies in an unsigned

-      zone or in a descendent of an unsigned zone.  In this case, the

-      RRset may or may not be signed, but the resolver will not be able

-      to verify the signature.

-

-   Bogus: An RRset for which the resolver believes that it ought to be

-      able to establish a chain of trust but is unable to do so, either

-      due to signatures that for some reason fail to validate or due to

-      missing data which the relevant DNSSEC RRs indicate should be

-      present.  This case may indicate an attack, but may also indicate

-      a configuration error or some form of data corruption.

-

-   Indeterminate: An RRset for which the resolver is not able to

-      determine whether or not the RRset should be signed, because the

-      resolver is not able to obtain the necessary DNSSEC RRs. This can

-      occur when the security-aware resolver is not able to contact

-      security-aware name servers for the relevant zones.

-

-4.4  Configured Trust Anchors

-

-   A security-aware resolver MUST be capable of being configured with at

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 21]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   least one trusted public key or DS RR, and SHOULD be capable of being

-   configured with multiple trusted public keys or DS RRs.  Since a

-   security-aware resolver will not be able to validate signatures

-   without such a configured trust anchor, the resolver SHOULD have some

-   reasonably robust mechanism for obtaining such keys when it boots;

-   examples of such a mechanism would be some form of non-volatile

-   storage (such as a disk drive) or some form of trusted local network

-   configuration mechanism.

-

-   Note that trust anchors also covers key material that is updated in a

-   secure manner.  This secure manner could be through physical media, a

-   key exchange protocol, or some other out of band means.

-

-4.5  Response Caching

-

-   A security-aware resolver SHOULD cache each response as a single

-   atomic entry containing the entire answer, including the named RRset

-   and any associated DNSSEC RRs.  The resolver SHOULD discard the

-   entire atomic entry when any of the RRs contained in it expire.  In

-   most cases the appropriate cache index for the atomic entry will be

-   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response

-   form described in Section 3.1.3.2 the appropriate cache index will be

-   the double <QNAME,QCLASS>.

-

-4.6  Handling of the CD and AD bits

-

-   A security-aware resolver MAY set the CD bit in a query to one in

-   order to indicate that the resolver takes responsibility for

-   performing whatever authentication its local policy requires on the

-   RRsets in the response.  See Section 3.2 for the effect this bit has

-   on the behavior of security-aware recursive name servers.

-

-   A security-aware resolver MUST zero the AD bit when composing query

-   messages to protect against buggy name servers which blindly copy

-   header bits which they do not understand from the query message to

-   the response message.

-

-   A resolver MUST disregard the meaning of the CD and AD bits in a

-   response unless the response was obtained using a secure channel or

-   the resolver was specifically configured to regard the message header

-   bits without using a secure channel.

-

-4.7  Caching BAD Data

-

-   While many validation errors will be transient, some are likely to be

-   more persistent, such as those caused by administrative error

-   (failure to re-sign a zone, clock skew, and so forth).  Since

-   requerying will not help in these cases, validating resolvers might

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 22]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   generate a significant amount of unnecessary DNS traffic as a result

-   of repeated queries for RRsets with persistent validation failures.

-

-   To prevent such unnecessary DNS traffic, security-aware resolvers MAY

-   cache data with invalid signatures, with some restrictions.

-   Conceptually, caching such data is similar to negative caching

-   [RFC2308], except that instead of caching a valid negative response,

-   the resolver is caching the fact that a particular answer failed to

-   validate.  This document refers to a cache of data with invalid

-   signatures as a "BAD cache".

-

-   Resolvers which implement a BAD cache MUST take steps to prevent the

-   cache from being useful as a denial-of-service attack amplifier.  In

-   particular:

-   o  Since RRsets which fail to validate do not have trustworthy TTLs,

-      the implementation MUST assign a TTL.  This TTL SHOULD be small,

-      in order to mitigate the effect of caching the results of an

-      attack.

-   o  In order to prevent caching of a transient validation failure

-      (which might be the result of an attack), resolvers SHOULD track

-      queries that result in validation failures, and SHOULD only answer

-      from the BAD cache after the number of times that responses to

-      queries for that particular <QNAME, QTYPE, QCLASS> have failed to

-      validate exceeds a threshold value.

-

-   Resolvers MUST NOT return RRsets from the BAD cache unless the

-   resolver is not required to validate the signatures of the RRsets in

-   question under the rules given in Section 4.2 of this document.  See

-   Section 3.2.2 for discussion of how the responses returned by a

-   security-aware recursive name server interact with a BAD cache.

-

-4.8  Synthesized CNAMEs

-

-   A validating security-aware resolver MUST treat the signature of a

-   valid signed DNAME RR as also covering unsigned CNAME RRs which could

-   have been synthesized from the DNAME RR as described in [RFC2672], at

-   least to the extent of not rejecting a response message solely

-   because it contains such CNAME RRs.  The resolver MAY retain such

-   CNAME RRs in its cache or in the answers it hands back, but is not

-   required to do so.

-

-4.9  Stub resolvers

-

-   A security-aware stub resolver MUST support the DNSSEC RR types, at

-   least to the extent of not mishandling responses just because they

-   contain DNSSEC RRs.

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 23]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-4.9.1  Handling of the DO Bit

-

-   A non-validating security-aware stub resolver MAY include the DNSSEC

-   RRs returned by a security-aware recursive name server as part of the

-   data that the stub resolver hands back to the application which

-   invoked it but is not required to do so.  A non-validating stub

-   resolver that wishes to do this will need to set the DO bit in

-   receive DNSSEC RRs from the recursive name server.

-

-   A validating security-aware stub resolver MUST set the DO bit, since

-   otherwise it will not receive the DNSSEC RRs it needs to perform

-   signature validation.

-

-4.9.2  Handling of the CD Bit

-

-   A non-validating security-aware stub resolver SHOULD NOT set the CD

-   bit when sending queries unless requested by the application layer,

-   since by definition, a non-validating stub resolver depends on the

-   security-aware recursive name server to perform validation on its

-   behalf.

-

-   A validating security-aware stub resolver SHOULD set the CD bit,

-   since otherwise the security-aware recursive name server will answer

-   the query using the name server's local policy, which may prevent the

-   stub resolver from receiving data which would be acceptable to the

-   stub resolver's local policy.

-

-4.9.3  Handling of the AD Bit

-

-   A non-validating security-aware stub resolver MAY chose to examine

-   the setting of the AD bit in response messages that it receives in

-   order to determine whether the security-aware recursive name server

-   which sent the response claims to have cryptographically verified the

-   data in the Answer and Authority sections of the response message.

-   Note, however, that the responses received by a security-aware stub

-   resolver are heavily dependent on the local policy of the

-   security-aware recursive name server, so as a practical matter there

-   may be little practical value to checking the status of the AD bit

-   except perhaps as a debugging aid.  In any case, a security-aware

-   stub resolver MUST NOT place any reliance on signature validation

-   allegedly performed on its behalf except when the security-aware stub

-   resolver obtained the data in question from a trusted security-aware

-   recursive name server via a secure channel.

-

-   A validating security-aware stub resolver SHOULD NOT examine the

-   setting of the AD bit in response messages, since, by definition, the

-   stub resolver performs its own signature validation regardless of the

-   setting of the AD bit.

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 24]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-5.  Authenticating DNS Responses

-

-   In order to use DNSSEC RRs for authentication, a security-aware

-   resolver requires configured knowledge of at least one authenticated

-   DNSKEY or DS RR.  The process for obtaining and authenticating this

-   initial trust anchors is achieved via some external mechanism.  For

-   example, a resolver could use some off-line authenticated exchange to

-   obtain a zone's DNSKEY RR or obtain a DS RR that identifies and

-   authenticates a zone's DNSKEY RR.  The remainder of this section

-   assumes that the resolver has somehow obtained an initial set of

-   trust anchors.

-

-   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY

-   RRset.  To authenticate an apex DNSKEY RRset using an initial key,

-   the resolver MUST:

-   1.  Verify that the initial DNSKEY RR appears in the apex DNSKEY

-       RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag

-       (DNSKEY RDATA bit 7) set to one.

-   2.  Verify that there is some RRSIG RR that covers the apex DNSKEY

-       RRset, and that the combination of the RRSIG RR and the initial

-       DNSKEY RR authenticates the DNSKEY RRset.  The process for using

-       an RRSIG RR to authenticate an RRset is described in Section 5.3.

-

-   Once the resolver has authenticated the apex DNSKEY RRset using an

-   initial DNSKEY RR, delegations from that zone can be authenticated

-   using DS RRs.  This allows a resolver to start from an initial key,

-   and use DS RRsets to proceed recursively down the DNS tree obtaining

-   other apex DNSKEY RRsets.  If the resolver were configured with a

-   root DNSKEY RR, and if every delegation had a DS RR associated with

-   it, then the resolver could obtain and validate any apex DNSKEY

-   RRset.  The process of using DS RRs to authenticate referrals is

-   described in Section 5.2.

-

-   Once the resolver has authenticated a zone's apex DNSKEY RRset,

-   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex

-   DNSKEY RRset and RRSIG RRs from the zone to authenticate any other

-   RRsets in the zone.  Section 5.4 shows how the resolver can use

-   authenticated NSEC RRsets from the zone to prove that an RRset is not

-   present in the zone.

-

-   When a resolver indicates support for DNSSEC (by setting the DO bit),

-   a security-aware name server should attempt to provide the necessary

-   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).

-   However, a security-aware resolver may still receive a response that

-   that lacks the appropriate DNSSEC RRs, whether due to configuration

-   issues such as an upstream security-oblivious recursive name server

-   that accidentally interferes with DNSSEC RRs or due to a deliberate

-   attack in which an adversary forges a response, strips DNSSEC RRs

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 25]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   from a response, or modifies a query so that DNSSEC RRs appear not to

-   be requested.  The absence of DNSSEC data in a response MUST NOT by

-   itself be taken as an indication that no authentication information

-   exists.

-

-   A resolver SHOULD expect authentication information from signed

-   zones. A resolver SHOULD believe that a zone is signed if the

-   resolver has been configured with public key information for the

-   zone, or if the zone's parent is signed and the delegation from the

-   parent contains a DS RRset.

-

-5.1  Special Considerations for Islands of Security

-

-   Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed

-   zones for which it is not possible to construct an authentication

-   chain to the zone from its parent.  Validating signatures within an

-   island of security requires the validator to have some other means of

-   obtaining an initial authenticated zone key for the island.  If a

-   validator cannot obtain such a key, it SHOULD switch to operating as

-   if the zones in the island of security are unsigned.

-

-   All the normal processes for validating responses apply to islands of

-   security.  The only difference between normal validation and

-   validation within an island of security is in how the validator

-   obtains a trust anchor for the authentication chain.

-

-5.2  Authenticating Referrals

-

-   Once the apex DNSKEY RRset for a signed parent zone has been

-   authenticated, DS RRsets can be used to authenticate the delegation

-   to a signed child zone.  A DS RR identifies a DNSKEY RR in the child

-   zone's apex DNSKEY RRset, and contains a cryptographic digest of the

-   child zone's DNSKEY RR.  A strong cryptographic digest algorithm

-   ensures that an adversary can not easily generate a DNSKEY RR that

-   matches the digest.  Thus, authenticating the digest allows a

-   resolver to authenticate the matching DNSKEY RR.  The resolver can

-   then use this child DNSKEY RR to authenticate the entire child apex

-   DNSKEY RRset.

-

-   Given a DS RR for a delegation, the child zone's apex DNSKEY RRset

-   can be authenticated if all of the following hold:

-   o  The DS RR has been authenticated using some DNSKEY RR in the

-      parent's apex DNSKEY RRset (see Section 5.3);

-   o  The Algorithm and Key Tag in the DS RR match the Algorithm field

-      and the key tag of a DNSKEY RR in the child zone's apex DNSKEY

-      RRset and, when hashed using the digest algorithm specified in the

-      DS RR's Digest Type field, results in a digest value that matches

-      the Digest field of the DS RR; and

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 26]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   o  The matching DNSKEY RR in the child zone has the Zone Flag bit set

-      to one, the corresponding private key has signed the child zone's

-      apex DNSKEY RRset, and the resulting RRSIG RR authenticates the

-      child zone's apex DNSKEY RRset.

-

-   If the referral from the parent zone did not contain a DS RRset, the

-   response should have included a signed NSEC RRset proving that no DS

-   RRset exists for the delegated name (see Section 3.1.4).  A

-   security-aware resolver MUST query the name servers for the parent

-   zone for the DS RRset if the referral includes neither a DS RRset nor

-   a NSEC RRset proving that the DS RRset does not exist (see Section

-   4).

-

-   If the validator authenticates an NSEC RRset that proves that no DS

-   RRset is present for this zone, then there is no authentication path

-   leading from the parent to the child.  If the resolver has an initial

-   DNSKEY or DS RR that belongs to the child zone or to any delegation

-   below the child zone, this initial DNSKEY or DS RR MAY be used to

-   re-establish an authentication path.  If no such initial DNSKEY or DS

-   RR exists, the validator can not authenticate RRsets in or below the

-   child zone.

-

-   If the validator does not support any of the algorithms listed in an

-   authenticated DS RRset, then the resolver has no supported

-   authentication path leading from the parent to the child.  The

-   resolver should treat this case as it would the case of an

-   authenticated NSEC RRset proving that no DS RRset exists, as

-   described above.

-

-   Note that, for a signed delegation, there are two NSEC RRs associated

-   with the delegated name.  One NSEC RR resides in the parent zone, and

-   can be used to prove whether a DS RRset exists for the delegated

-   name.  The second NSEC RR resides in the child zone, and identifies

-   which RRsets are present at the apex of the child zone.  The parent

-   NSEC RR and child NSEC RR can always be distinguished, since the SOA

-   bit will be set in the child NSEC RR and clear in the parent NSEC RR.

-   A security-aware resolver MUST use the parent NSEC RR when attempting

-   to prove that a DS RRset does not exist.

-

-   If the resolver does not support any of the algorithms listed in an

-   authenticated DS RRset, then the resolver will not be able to verify

-   the authentication path to the child zone.  In this case, the

-   resolver SHOULD treat the child zone as if it were unsigned.

-

-5.3  Authenticating an RRset Using an RRSIG RR

-

-   A validator can use an RRSIG RR and its corresponding DNSKEY RR to

-   attempt to authenticate RRsets.  The validator first checks the RRSIG

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 27]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   RR to verify that it covers the RRset, has a valid time interval, and

-   identifies a valid DNSKEY RR.  The validator then constructs the

-   canonical form of the signed data by appending the RRSIG RDATA

-   (excluding the Signature Field) with the canonical form of the

-   covered RRset.  Finally, the validator uses the public key and

-   signature to authenticate the signed data.  Section 5.3.1, Section

-   5.3.2, and Section 5.3.3 describe each step in detail.

-

-5.3.1  Checking the RRSIG RR Validity

-

-   A security-aware resolver can use an RRSIG RR to authenticate an

-   RRset if all of the following conditions hold:

-   o  The RRSIG RR and the RRset MUST have the same owner name and the

-      same class;

-   o  The RRSIG RR's Signer's Name field MUST be the name of the zone

-      that contains the RRset;

-   o  The RRSIG RR's Type Covered field MUST equal the RRset's type;

-   o  The number of labels in the RRset owner name MUST be greater than

-      or equal to the value in the RRSIG RR's Labels field;

-   o  The validator's notion of the current time MUST be less than or

-      equal to the time listed in the RRSIG RR's Expiration field;

-   o  The validator's notion of the current time MUST be greater than or

-      equal to the time listed in the RRSIG RR's Inception field;

-   o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST

-      match the owner name, algorithm, and key tag for some DNSKEY RR in

-      the zone's apex DNSKEY RRset;

-   o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY

-      RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)

-      set to one.

-

-   It is possible for more than one DNSKEY RR to match the conditions

-   above.  In this case, the validator cannot predetermine which DNSKEY

-   RR to use to authenticate the signature, MUST try each matching

-   DNSKEY RR until either the signature is validated or the validator

-   has run out of matching public keys to try.

-

-   Note that this authentication process is only meaningful if the

-   validator authenticates the DNSKEY RR before using it to validate

-   signatures.  The matching DNSKEY RR is considered to be authentic if:

-   o  The apex DNSKEY RRset containing the DNSKEY RR is considered

-      authentic; or

-   o  The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,

-      and the DNSKEY RR either matches an authenticated DS RR from the

-      parent zone or matches a trust anchor.

-

-5.3.2  Reconstructing the Signed Data

-

-   Once the RRSIG RR has met the validity requirements described in

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 28]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   Section 5.3.1, the validator needs to reconstruct the original signed

-   data.  The original signed data includes RRSIG RDATA (excluding the

-   Signature field) and the canonical form of the RRset.  Aside from

-   being ordered, the canonical form of the RRset might also differ from

-   the received RRset due to DNS name compression, decremented TTLs, or

-   wildcard expansion.  The validator should use the following to

-   reconstruct the original signed data:

-

-         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where

-

-            "|" denotes concatenation

-

-            RRSIG_RDATA is the wire format of the RRSIG RDATA fields

-               with the Signature field excluded and the Signer's Name

-               in canonical form.

-

-            RR(i) = name | type | class | OrigTTL | RDATA length | RDATA

-

-               name is calculated according to the function below

-

-               class is the RRset's class

-

-               type is the RRset type and all RRs in the class

-

-               OrigTTL is the value from the RRSIG Original TTL field

-

-               All names in the RDATA field are in canonical form

-

-               The set of all RR(i) is sorted into canonical order.

-

-            To calculate the name:

-               let rrsig_labels = the value of the RRSIG Labels field

-

-               let fqdn = RRset's fully qualified domain name in

-                               canonical form

-

-               let fqdn_labels = Label count of the fqdn above.

-

-               if rrsig_labels = fqdn_labels,

-                   name = fqdn

-

-               if rrsig_labels < fqdn_labels,

-                  name = "*." | the rightmost rrsig_label labels of the

-                                fqdn

-

-               if rrsig_labels > fqdn_labels

-                  the RRSIG RR did not pass the necessary validation

-                  checks and MUST NOT be used to authenticate this

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 29]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-                  RRset.

-

-   The canonical forms for names and RRsets are defined in

-   [I-D.ietf-dnsext-dnssec-records].

-

-   NSEC RRsets at a delegation boundary require special processing.

-   There are two distinct NSEC RRsets associated with a signed delegated

-   name.  One NSEC RRset resides in the parent zone, and specifies which

-   RRset are present at the parent zone.  The second NSEC RRset resides

-   at the child zone, and identifies which RRsets are present at the

-   apex in the child zone.  The parent NSEC RRset and child NSEC RRset

-   can always be distinguished since only the child NSEC RRs will

-   specify an SOA RRset exists at the name. When reconstructing the

-   original NSEC RRset for the delegation from the parent zone, the NSEC

-   RRs MUST NOT be combined with NSEC RRs from the child zone, and when

-   reconstructing the original NSEC RRset for the apex of the child

-   zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent

-   zone.

-

-   Note also that each of the two NSEC RRsets at a delegation point has

-   a corresponding RRSIG RR with an owner name matching the delegated

-   name, and each of these RRSIG RRs is authoritative data associated

-   with the same zone that contains the corresponding NSEC RRset.  If

-   necessary, a resolver can tell these RRSIG RRs apart by checking the

-   Signer's Name field.

-

-5.3.3  Checking the Signature

-

-   Once the resolver has validated the RRSIG RR as described in Section

-   5.3.1 and reconstructed the original signed data as described in

-   Section 5.3.2, the validator can attempt to use the cryptographic

-   signature to authenticate the signed data, and thus (finally!)

-   authenticate the RRset.

-

-   The Algorithm field in the RRSIG RR identifies the cryptographic

-   algorithm used to generate the signature.  The signature itself is

-   contained in the Signature field of the RRSIG RDATA, and the public

-   key used to verify the signature is contained in the Public Key field

-   of the matching DNSKEY RR(s) (found in Section 5.3.1).

-   [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types

-   and provides pointers to the documents that define each algorithm's

-   use.

-

-   Note that it is possible for more than one DNSKEY RR to match the

-   conditions in Section 5.3.1.  In this case, the validator can only

-   determine which DNSKEY RR by trying each matching public key until

-   the validator either succeeds in validating the signature or runs out

-   of keys to try.

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 30]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   If the Labels field of the RRSIG RR is not equal to the number of

-   labels in the RRset's fully qualified owner name, then the RRset is

-   either invalid or the result of wildcard expansion.  The resolver

-   MUST verify that wildcard expansion was applied properly before

-   considering the RRset to be authentic.  Section 5.3.4 describes how

-   to determine whether a wildcard was applied properly.

-

-   If other RRSIG RRs also cover this RRset, the local resolver security

-   policy determines whether the resolver also needs to test these RRSIG

-   RRs, and determines how to resolve conflicts if these RRSIG RRs lead

-   to differing results.

-

-   If the resolver accepts the RRset as authentic, the validator MUST

-   set the TTL of the RRSIG RR and each RR in the authenticated RRset to

-   a value no greater than the minimum of:

-   o  The RRset's TTL as received in the response;

-   o  The RRSIG RR's TTL as received in the response;

-   o  The value in the RRSIG RR's Original TTL field; and

-   o  The difference of the RRSIG RR's Signature Expiration time and the

-      current time.

-

-5.3.4  Authenticating A Wildcard Expanded RRset Positive Response

-

-   If the number of labels in an RRset's owner name is greater than the

-   Labels field of the covering RRSIG RR, then the RRset and its

-   covering RRSIG RR were created as a result of wildcard expansion.

-   Once the validator has verified the signature as described in Section

-   5.3, it must take additional steps to verify the non-existence of an

-   exact match or closer wildcard match for the query.  Section 5.4

-   discusses these steps.

-

-   Note that the response received by the resolver should include all

-   NSEC RRs needed to authenticate the response (see Section 3.1.3).

-

-5.4  Authenticated Denial of Existence

-

-   A resolver can use authenticated NSEC RRs to prove that an RRset is

-   not present in a signed zone.  Security-aware name servers should

-   automatically include any necessary NSEC RRs for signed zones in

-   their responses to security-aware resolvers.

-

-   Security-aware resolvers MUST first authenticate NSEC RRsets

-   according to the standard RRset authentication rules described in

-   Section 5.3, then apply the NSEC RRsets as follows:

-   o  If the requested RR name matches the owner name of an

-      authenticated NSEC RR, then the NSEC RR's type bit map field lists

-      all RR types present at that owner name, and a resolver can prove

-      that the requested RR type does not exist by checking for the RR

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 31]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-      type in the bit map.  If the number of labels in an authenticated

-      NSEC RR's owner name equals the Labels field of the covering RRSIG

-      RR, then the existence of the NSEC RR proves that wildcard

-      expansion could not have been used to match the request.

-   o  If the requested RR name would appear after an authenticated NSEC

-      RR's owner name and before the name listed in that NSEC RR's Next

-      Domain Name field according to the canonical DNS name order

-      defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with

-      the requested name exist in the zone.  However, it is possible

-      that a wildcard could be used to match the requested RR owner name

-      and type, so proving that the requested RRset does not exist also

-      requires proving that no possible wildcard RRset exists that could

-      have been used to generate a positive response.

-

-   To prove non-existence of an RRset, the resolver must be able to

-   verify both that the queried RRset does not exist and that no

-   relevant wildcard RRset exists.  Proving this may require more than

-   one NSEC RRset from the zone.  If the complete set of necessary NSEC

-   RRsets is not present in a response (perhaps due to message

-   truncation), then a security-aware resolver MUST resend the query in

-   order to attempt to obtain the full collection of NSEC RRs necessary

-   to verify non-existence of the requested RRset.  As with all DNS

-   operations, however, the resolver MUST bound the work it puts into

-   answering any particular query.

-

-   Since a validated NSEC RR proves the existence of both itself and its

-   corresponding RRSIG RR, a validator MUST ignore the settings of the

-   NSEC and RRSIG bits in an NSEC RR.

-

-5.5  Resolver Behavior When Signatures Do Not Validate

-

-   If for whatever reason none of the RRSIGs can be validated, the

-   response SHOULD be considered BAD.  If the validation was being done

-   to service a recursive query, the name server MUST return RCODE 2 to

-   the originating client.  However, it MUST return the full response if

-   and only if the original query had the CD bit set. See also Section

-   4.7 on caching responses that do not validate.

-

-5.6  Authentication Example

-

-   Appendix C shows an example the authentication process.

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 32]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-6.  IANA Considerations

-

-   [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA

-   considerations introduced by DNSSEC.  The additional IANA

-   considerations discussed in this document:

-

-   [RFC2535] reserved the CD and AD bits in the message header.  The

-   meaning of the AD bit was redefined in [RFC3655] and the meaning of

-   both the CD and AD bit are restated in this document.  No new bits in

-   the DNS message header are defined in this document.

-

-   [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit

-   and defined its use.  The use is restated but not altered in this

-   document.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 33]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-7.  Security Considerations

-

-   This document describes how the DNS security extensions use public

-   key cryptography to sign and authenticate DNS resource record sets.

-   Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general

-   security considerations related to DNSSEC; see

-   [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the

-   DNSSEC resource record types.

-

-   An active attacker who can set the CD bit in a DNS query message or

-   the AD bit in a DNS response message can use these bits to defeat the

-   protection which DNSSEC attempts to provide to security-oblivious

-   recursive-mode resolvers.  For this reason, use of these control bits

-   by a security-aware recursive-mode resolver requires a secure

-   channel.  See Section 3.2.2 and Section 4.9 for further discussion.

-

-   The protocol described in this document attempts to extend the

-   benefits of DNSSEC to security-oblivious stub resolvers. However,

-   since recovery from validation failures is likely to be specific to

-   particular applications, the facilities that DNSSEC provides for stub

-   resolvers may prove inadequate.  Operators of security-aware

-   recursive name servers will need to pay close attention to the

-   behavior of the applications which use their services when choosing a

-   local validation policy; failure to do so could easily result in the

-   recursive name server accidentally denying service to the clients it

-   is intended to support.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 34]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-8.  Acknowledgements

-

-   This document was created from the input and ideas of the members of

-   the DNS Extensions Working Group and working group mailing list.  The

-   editors would like to express their thanks for the comments and

-   suggestions received during the revision of these security extension

-   specifications.  While explicitly listing everyone who has

-   contributed during the decade during which DNSSEC has been under

-   development would be an impossible task,

-   [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the

-   participants who were kind enough to comment on these documents.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 35]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-9.  References

-

-9.1  Normative References

-

-   [I-D.ietf-dnsext-dnssec-intro]

-              Arends, R., Austein, R., Larson, M., Massey, D. and S.

-              Rose, "DNS Security Introduction and Requirements",

-              draft-ietf-dnsext-dnssec-intro-10 (work in progress), May

-              2004.

-

-   [I-D.ietf-dnsext-dnssec-records]

-              Arends, R., Austein, R., Larson, M., Massey, D. and S.

-              Rose, "Resource Records for DNS Security Extensions",

-              draft-ietf-dnsext-dnssec-records-08 (work in progress),

-              May 2004.

-

-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",

-              STD 13, RFC 1034, November 1987.

-

-   [RFC1035]  Mockapetris, P., "Domain names - implementation and

-              specification", STD 13, RFC 1035, November 1987.

-

-   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,

-              August 1996.

-

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

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

-

-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS

-              Specification", RFC 2181, July 1997.

-

-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC

-              2671, August 1999.

-

-   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC

-              2672, August 1999.

-

-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC

-              3225, December 2001.

-

-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver

-              message size requirements", RFC 3226, December 2001.

-

-9.2  Informative References

-

-   [I-D.ietf-dnsext-nsec-rdata]

-              Schlyter, J., "KEY RR Secure Entry Point Flag",

-              draft-ietf-dnsext-nsec-rdata-05 (work in progress), March

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 36]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-              2004.

-

-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS

-              NCACHE)", RFC 2308, March 1998.

-

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

-              RFC 2535, March 1999.

-

-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY

-              RR)", RFC 2930, September 2000.

-

-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (

-              SIG(0)s)", RFC 2931, September 2000.

-

-   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS

-              Authenticated Data (AD) bit", RFC 3655, November 2003.

-

-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record

-              (RR)", RFC 3658, December 2003.

-

-

-Authors' Addresses

-

-   Roy Arends

-   Telematica Instituut

-   Drienerlolaan 5

-   7522 NB  Enschede

-   NL

-

-   EMail: roy.arends@telin.nl

-

-

-   Matt Larson

-   VeriSign, Inc.

-   21345 Ridgetop Circle

-   Dulles, VA  20166-6503

-   USA

-

-   EMail: mlarson@verisign.com

-

-

-   Rob Austein

-   Internet Systems Consortium

-   950 Charter Street

-   Redwood City, CA  94063

-   USA

-

-   EMail: sra@isc.org

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 37]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   Dan Massey

-   USC Information Sciences Institute

-   3811 N. Fairfax Drive

-   Arlington, VA  22203

-   USA

-

-   EMail: masseyd@isi.edu

-

-

-   Scott Rose

-   National Institute for Standards and Technology

-   100 Bureau Drive

-   Gaithersburg, MD  20899-8920

-   USA

-

-   EMail: scott.rose@nist.gov

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 38]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-Appendix A.  Signed Zone Example

-

-   The following example shows a (small) complete signed zone.

-

-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (

-                              1081539377

-                              3600

-                              300

-                              3600000

-                              3600

-                              )

-                  3600 RRSIG  SOA 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h

-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF

-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW

-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB

-                              jV7j86HyQgM5e7+miRAz8V01b0I= )

-                  3600 NS     ns1.example.

-                  3600 NS     ns2.example.

-                  3600 RRSIG  NS 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd

-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf

-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8

-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48

-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )

-                  3600 MX     1 xx.example.

-                  3600 RRSIG  MX 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB

-                              2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE

-                              VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO

-                              6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM

-                              W6OISukd1EQt7a0kygkg+PEDxdI= )

-                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY

-                  3600 RRSIG  NSEC 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm

-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V

-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW

-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm

-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )

-                  3600 DNSKEY 256 3 5 (

-                              AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV

-                              rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e

-                              k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo

-                              vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 39]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-                              ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==

-                              )

-                  3600 DNSKEY 257 3 5 (

-                              AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl

-                              LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ

-                              syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP

-                              RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT

-                              Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==

-                              )

-                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (

-                              20040409183619 9465 example.

-                              ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ

-                              xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ

-                              XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9

-                              hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY

-                              NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )

-                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z

-                              DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri

-                              bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp

-                              eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk

-                              7z5OXogYVaFzHKillDt3HRxHIZM= )

-   a.example.     3600 IN NS  ns1.a.example.

-                  3600 IN NS  ns2.a.example.

-                  3600 DS     57855 5 1 (

-                              B6DCD485719ADCA18E5F3D48A2331627FDD3

-                              636B )

-                  3600 RRSIG  DS 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ

-                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH

-                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD

-                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/

-                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )

-                  3600 NSEC   ai.example. NS DS RRSIG NSEC

-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba

-                              U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2

-                              039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I

-                              BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g

-                              sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )

-   ns1.a.example. 3600 IN A   192.0.2.5

-   ns2.a.example. 3600 IN A   192.0.2.6

-   ai.example.    3600 IN A   192.0.2.9

-                  3600 RRSIG  A 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 40]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B

-                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd

-                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u

-                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy

-                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )

-                  3600 HINFO  "KLH-10" "ITS"

-                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l

-                              e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh

-                              ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7

-                              AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw

-                              FvL8sqlS5QS6FY/ijFEDnI4RkZA= )

-                  3600 AAAA   2001:db8::f00:baa9

-                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK

-                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh

-                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T

-                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2

-                              sZM6QjBBLmukH30+w1z3h8PUP2o= )

-                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC

-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG

-                              CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p

-                              P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN

-                              3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL

-                              AhS+JOVfDI/79QtyTI0SaDWcg8U= )

-   b.example.     3600 IN NS  ns1.b.example.

-                  3600 IN NS  ns2.b.example.

-                  3600 NSEC   ns1.example. NS RRSIG NSEC

-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx

-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS

-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs

-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ

-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )

-   ns1.b.example. 3600 IN A   192.0.2.7

-   ns2.b.example. 3600 IN A   192.0.2.8

-   ns1.example.   3600 IN A   192.0.2.1

-                  3600 RRSIG  A 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet

-                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06

-                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+

-                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 41]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-                              v/iVXSYC0b7mPSU+EOlknFpVECs= )

-                  3600 NSEC   ns2.example. A RRSIG NSEC

-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8

-                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB

-                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq

-                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8

-                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )

-   ns2.example.   3600 IN A   192.0.2.2

-                  3600 RRSIG  A 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq

-                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu

-                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO

-                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq

-                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )

-                  3600 NSEC   *.w.example. A RRSIG NSEC

-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE

-                              VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb

-                              3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH

-                              l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw

-                              Ymx28EtgIpo9A0qmP08rMBqs1Jw= )

-   *.w.example.   3600 IN MX  1 ai.example.

-                  3600 RRSIG  MX 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2

-                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc

-                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X

-                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw

-                              4kX18MMR34i8lC36SR5xBni8vHI= )

-                  3600 NSEC   x.w.example. MX RRSIG NSEC

-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9

-                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU

-                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx

-                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8

-                              s1InQ2UoIv6tJEaaKkP701j8OLA= )

-   x.w.example.   3600 IN MX  1 xx.example.

-                  3600 RRSIG  MX 5 3 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1

-                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP

-                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I

-                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 42]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )

-                  3600 NSEC   x.y.w.example. MX RRSIG NSEC

-                  3600 RRSIG  NSEC 5 3 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK

-                              vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E

-                              mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI

-                              NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e

-                              IjgiM8PXkBQtxPq37wDKALkyn7Q= )

-   x.y.w.example. 3600 IN MX  1 xx.example.

-                  3600 RRSIG  MX 5 4 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia

-                              t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj

-                              q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq

-                              GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb

-                              +gLcMZBnHJ326nb/TOOmrqNmQQE= )

-                  3600 NSEC   xx.example. MX RRSIG NSEC

-                  3600 RRSIG  NSEC 5 4 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp

-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg

-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX

-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr

-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )

-   xx.example.    3600 IN A   192.0.2.10

-                  3600 RRSIG  A 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP

-                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa

-                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y

-                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx

-                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )

-                  3600 HINFO  "KLH-10" "TOPS-20"

-                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0

-                              t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq

-                              BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8

-                              3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+

-                              RgNvuwbioFSEuv2pNlkq0goYxNY= )

-                  3600 AAAA   2001:db8::f00:baaa

-                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C

-                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z

-                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr

-                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 43]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-                              xS9cL2QgW7FChw16mzlkH6/vsfs= )

-                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC

-                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY

-                              9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k

-                              mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi

-                              asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W

-                              GghLahumFIpg4MO3LS/prgzVVWo= )

-

-   The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA

-   Flags indicate that each of these DNSKEY RRs is a zone key.  One of

-   these DNSKEY RRs also has the SEP flag set and has been used to sign

-   the apex DNSKEY RRset; this is the key which should be hashed to

-   generate a DS record to be inserted into the parent zone.  The other

-   DNSKEY is used to sign all the other RRsets in the zone.

-

-   The zone includes a wildcard entry "*.w.example".  Note that the name

-   "*.w.example" is used in constructing NSEC chains, and that the RRSIG

-   covering the "*.w.example" MX RRset has a label count of 2.

-

-   The zone also includes two delegations.  The delegation to

-   "b.example" includes an NS RRset, glue address records, and an NSEC

-   RR; note that only the NSEC RRset is signed.  The delegation to

-   "a.example" provides a DS RR; note that only the NSEC and DS RRsets

-   are signed.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 44]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-Appendix B.  Example Responses

-

-   The examples in this section show response messages using the signed

-   zone example in Appendix A.

-

-B.1  Answer

-

-   A successful query to an authoritative server.

-

-   ;; Header: QR AA DO RCODE=0

-   ;;

-   ;; Question

-   x.w.example.        IN MX

-

-   ;; Answer

-   x.w.example.   3600 IN MX  1 xx.example.

-   x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1

-                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP

-                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I

-                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1

-                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )

-

-   ;; Authority

-   example.       3600 NS     ns1.example.

-   example.       3600 NS     ns2.example.

-   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd

-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf

-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8

-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48

-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )

-

-   ;; Additional

-   xx.example.    3600 IN A   192.0.2.10

-   xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP

-                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa

-                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y

-                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx

-                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )

-   xx.example.    3600 AAAA   2001:db8::f00:baaa

-   xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 45]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z

-                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr

-                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/

-                              xS9cL2QgW7FChw16mzlkH6/vsfs= )

-   ns1.example.   3600 IN A   192.0.2.1

-   ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet

-                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06

-                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+

-                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK

-                              v/iVXSYC0b7mPSU+EOlknFpVECs= )

-   ns2.example.   3600 IN A   192.0.2.2

-   ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq

-                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu

-                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO

-                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq

-                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )

-

-

-B.2  Name Error

-

-   An authoritative name error.  The NSEC RRs prove that the name does

-   not exist and that no covering wildcard exists.

-

-   ;; Header: QR AA DO RCODE=3

-   ;;

-   ;; Question

-   ml.example.         IN A

-

-   ;; Answer

-   ;; (empty)

-

-   ;; Authority

-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (

-                              1081539377

-                              3600

-                              300

-                              3600000

-                              3600

-                              )

-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h

-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF

-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 46]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB

-                              jV7j86HyQgM5e7+miRAz8V01b0I= )

-   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC

-   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx

-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS

-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs

-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ

-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )

-   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY

-   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm

-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V

-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW

-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm

-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )

-

-   ;; Additional

-   ;; (empty)

-

-

-B.3  No Data Error

-

-   A "NODATA" response.  The NSEC RR proves that the name exists and

-   that the requested RR type does not.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 47]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   ;; Header: QR AA DO RCODE=0

-   ;;

-   ;; Question

-   ns1.example.        IN MX

-

-   ;; Answer

-   ;; (empty)

-

-   ;; Authority

-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (

-                              1081539377

-                              3600

-                              300

-                              3600000

-                              3600

-                              )

-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h

-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF

-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW

-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB

-                              jV7j86HyQgM5e7+miRAz8V01b0I= )

-   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC

-   ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8

-                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB

-                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq

-                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8

-                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )

-

-   ;; Additional

-   ;; (empty)

-

-

-B.4  Referral to Signed Zone

-

-   Referral to a signed zone.   The DS RR contains the data which the

-   resolver will need to validate the corresponding DNSKEY RR in the

-   child zone's apex.

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 48]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   ;; Header: QR DO RCODE=0

-   ;;

-   ;; Question

-   mc.a.example.       IN MX

-

-   ;; Answer

-   ;; (empty)

-

-   ;; Authority

-   a.example.     3600 IN NS  ns1.a.example.

-   a.example.     3600 IN NS  ns2.a.example.

-   a.example.     3600 DS     57855 5 1 (

-                              B6DCD485719ADCA18E5F3D48A2331627FDD3

-                              636B )

-   a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ

-                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH

-                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD

-                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/

-                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )

-

-   ;; Additional

-   ns1.a.example. 3600 IN A   192.0.2.5

-   ns2.a.example. 3600 IN A   192.0.2.6

-

-

-B.5  Referral to Unsigned Zone

-

-   Referral to an unsigned zone.  The NSEC RR proves that no DS RR for

-   this delegation exists in the parent zone.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 49]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   ;; Header: QR DO RCODE=0

-   ;;

-   ;; Question

-   mc.b.example.       IN MX

-

-   ;; Answer

-   ;; (empty)

-

-   ;; Authority

-   b.example.     3600 IN NS  ns1.b.example.

-   b.example.     3600 IN NS  ns2.b.example.

-   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC

-   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx

-                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS

-                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs

-                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ

-                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )

-

-   ;; Additional

-   ns1.b.example. 3600 IN A   192.0.2.7

-   ns2.b.example. 3600 IN A   192.0.2.8

-

-

-B.6  Wildcard Expansion

-

-   A successful query which was answered via wildcard expansion. The

-   label count in the answer's RRSIG RR indicates that a wildcard RRset

-   was expanded to produce this response, and the NSEC RR proves that no

-   closer match exists in the zone.

-

-   ;; Header: QR AA DO RCODE=0

-   ;;

-   ;; Question

-   a.z.w.example.      IN MX

-

-   ;; Answer

-   a.z.w.example. 3600 IN MX  1 ai.example.

-   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2

-                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc

-                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X

-                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw

-                              4kX18MMR34i8lC36SR5xBni8vHI= )

-

-   ;; Authority

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 50]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   example.       3600 NS     ns1.example.

-   example.       3600 NS     ns2.example.

-   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd

-                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf

-                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8

-                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48

-                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )

-   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC

-   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp

-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg

-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX

-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr

-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )

-

-   ;; Additional

-   ai.example.    3600 IN A   192.0.2.9

-   ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B

-                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd

-                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u

-                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy

-                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )

-   ai.example.    3600 AAAA   2001:db8::f00:baa9

-   ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK

-                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh

-                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T

-                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2

-                              sZM6QjBBLmukH30+w1z3h8PUP2o= )

-

-

-B.7  Wildcard No Data Error

-

-   A "NODATA" response for a name covered by a wildcard.  The NSEC RRs

-   prove that the matching wildcard name does not have any RRs of the

-   requested type and that no closer match exists in the zone.

-

-   ;; Header: QR AA DO RCODE=0

-   ;;

-   ;; Question

-   a.z.w.example.      IN AAAA

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 51]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   ;; Answer

-   ;; (empty)

-

-   ;; Authority

-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (

-                              1081539377

-                              3600

-                              300

-                              3600000

-                              3600

-                              )

-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h

-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF

-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW

-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB

-                              jV7j86HyQgM5e7+miRAz8V01b0I= )

-   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC

-   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp

-                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg

-                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX

-                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr

-                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )

-   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC

-   *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9

-                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU

-                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx

-                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8

-                              s1InQ2UoIv6tJEaaKkP701j8OLA= )

-

-   ;; Additional

-   ;; (empty)

-

-

-B.8  DS Child Zone No Data Error

-

-   A "NODATA" response for a QTYPE=DS query which was mistakenly sent to

-   a name server for the child zone.

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 52]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   ;; Header: QR AA DO RCODE=0

-   ;;

-   ;; Question

-   example.            IN DS

-

-   ;; Answer

-   ;; (empty)

-

-   ;; Authority

-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (

-                              1081539377

-                              3600

-                              300

-                              3600000

-                              3600

-                              )

-   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h

-                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF

-                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW

-                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB

-                              jV7j86HyQgM5e7+miRAz8V01b0I= )

-   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY

-   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (

-                              20040409183619 38519 example.

-                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm

-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V

-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW

-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm

-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )

-

-   ;; Additional

-   ;; (empty)

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 53]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-Appendix C.  Authentication Examples

-

-   The examples in this section show how the response messages in

-   Appendix B are authenticated.

-

-C.1  Authenticating An Answer

-

-   The query in section Appendix B.1 returned an MX RRset for

-   "x.w.example.com".  The corresponding RRSIG indicates the MX RRset

-   was signed by an "example" DNSKEY with algorithm 5 and key tag 38519.

-   The resolver needs the corresponding DNSKEY RR in order to

-   authenticate this answer.  The discussion below describes how a

-   resolver might obtain this DNSKEY RR.

-

-   The RRSIG indicates the original TTL of the MX RRset was 3600 and,

-   for the purpose of authentication, the current TTL is replaced by

-   3600.  The RRSIG labels field value of 3 indicates the answer was not

-   the result of wildcard expansion.  The "x.w.example.com" MX RRset is

-   placed in canonical form and, assuming the current time falls between

-   the signature inception and expiration dates, the signature is

-   authenticated.

-

-C.1.1  Authenticating the example DNSKEY RR

-

-   This example shows the logical authentication process that starts

-   from the a configured root DNSKEY (or DS RR) and moves down the tree

-   to authenticate the desired "example" DNSKEY RR.  Note the logical

-   order is presented for clarity and an implementation may choose to

-   construct the authentication as referrals are received or may choose

-   to construct the authentication chain only after all RRsets have been

-   obtained, or in any other combination it sees fit.  The example here

-   demonstrates only the logical process and does not dictate any

-   implementation rules.

-

-   We assume the resolver starts with an configured DNSKEY RR for the

-   root zone (or a configured DS RR for the root zone).  The resolver

-   checks this configured DNSKEY RR is present in the root DNSKEY RRset

-   (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this

-   DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime

-   is valid.  If all these conditions are met, all keys in the DNSKEY

-   RRset are considered authenticated. The resolver then uses one (or

-   more) of the root DNSKEY RRs to authenticate the "example" DS RRset.

-   Note the resolver may need to query the root zone to obtain the root

-   DNSKEY RRset or "example" DS RRset.

-

-   Once the DS RRset has been authenticated using the root DNSKEY, the

-   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY

-   RR that matches one of the authenticated "example" DS RRs.  If such a

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 54]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   matching "example" DNSKEY is found, the resolver checks this DNSKEY

-   RR has signed the "example" DNSKEY RRset and the signature lifetime

-   is valid.  If all these conditions are met, all keys in the "example"

-   DNSKEY RRset are considered authenticated.

-

-   Finally the resolver checks that some DNSKEY RR in the "example"

-   DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY

-   is used to authenticated the RRSIG included in the response.  If

-   multiple "example" DNSKEY RRs match this algorithm and key tag, then

-   each DNSKEY RR is tried and the answer is authenticated if any of the

-   matching DNSKEY RRs validates the signature as described above.

-

-C.2  Name Error

-

-   The query in section Appendix B.2 returned NSEC RRs that prove the

-   requested data does not exist and no wildcard applies.  The negative

-   reply is authenticated by verifying both NSEC RRs.  The NSEC RRs are

-   authenticated in a manner identical to that of the MX RRset discussed

-   above.

-

-C.3  No Data Error

-

-   The query in section Appendix B.3 returned an NSEC RR that proves the

-   requested name exists, but the requested RR type does not exist. The

-   negative reply is authenticated by verifying the NSEC RR.  The NSEC

-   RR is authenticated in a manner identical to that of the MX RRset

-   discussed above.

-

-C.4  Referral to Signed Zone

-

-   The query in section Appendix B.4 returned a referral to the signed

-   "a.example." zone.  The DS RR is authenticated in a manner identical

-   to that of the MX RRset discussed above.  This DS RR is used to

-   authenticate the "a.example" DNSKEY RRset.

-

-   Once the "a.example" DS RRset has been authenticated using the

-   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset

-   for some "a.example" DNSKEY RR that matches the DS RR.  If such a

-   matching "a.example" DNSKEY is found, the resolver checks this DNSKEY

-   RR has signed the "a.example" DNSKEY RRset and the signature lifetime

-   is valid.  If all these conditions are met, all keys in the

-   "a.example" DNSKEY RRset are considered authenticated.

-

-C.5  Referral to Unsigned Zone

-

-   The query in section Appendix B.5 returned a referral to an unsigned

-   "b.example." zone.  The NSEC proves that no authentication leads from

-   "example" to "b.example" and the NSEC RR is authenticated in a manner

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 55]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-   identical to that of the MX RRset discussed above.

-

-C.6  Wildcard Expansion

-

-   The query in section Appendix B.6 returned an answer that was

-   produced as a result of wildcard expansion. The RRset expanded as the

-   similar to The corresponding RRSIG indicates the MX RRset was signed

-   by an "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG

-   indicates the original TTL of the MX RRset was 3600 and, for the

-   purpose of authentication, the current TTL is replaced by 3600.  The

-   RRSIG labels field value of 2 indicates the answer the result of

-   wildcard expansion since the "a.z.w.example" name contains 4 labels.

-   The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset

-   is placed in canonical form and, assuming the current time falls

-   between the signature inception and expiration dates, the signature

-   is authenticated.

-

-   The NSEC proves that no closer match (exact or closer wildcard) could

-   have been used to answer this query and the NSEC RR must also be

-   authenticated before the answer is considered valid.

-

-C.7  Wildcard No Data Error

-

-   The query in section Appendix B.7 returned NSEC RRs that prove the

-   requested data does not exist and no wildcard applies.  The negative

-   reply is authenticated by verifying both NSEC RRs.

-

-C.8  DS Child Zone No Data Error

-

-   The query in section Appendix B.8 returned NSEC RRs that shows the

-   requested was answered by a child server ("example" server).  The

-   NSEC RR indicates the presence of an SOA RR, showing the answer is

-   from the child .  Queries for the "example" DS RRset should be sent

-   to the parent servers ("root" servers).

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 56]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

-Intellectual Property Statement

-

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

-   intellectual property or other rights that might be claimed to

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

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

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

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

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

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

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

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

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

-   proprietary rights by implementors or users of this specification can

-   be obtained from the IETF Secretariat.

-

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

-   copyrights, patents or patent applications, or other proprietary

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

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

-   Director.

-

-

-Full Copyright Statement

-

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

-

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

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

-   or assist in its implementation may be prepared, copied, published

-   and distributed, in whole or in part, without restriction of any

-   kind, provided that the above copyright notice and this paragraph are

-   included on all such copies and derivative works. However, this

-   document itself may not be modified in any way, such as by removing

-   the copyright notice or references to the Internet Society or other

-   Internet organizations, except as needed for the purpose of

-   developing Internet standards in which case the procedures for

-   copyrights defined in the Internet Standards process must be

-   followed, or as required to translate it into languages other than

-   English.

-

-   The limited permissions granted above are perpetual and will not be

-   revoked by the Internet Society or its successors or assignees.

-

-   This document and the information contained herein is provided on an

-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 57]

-

-Internet-Draft       DNSSEC Protocol Modifications              May 2004

-

-

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

-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Acknowledgment

-

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

-   Internet Society.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 58]

-

-

+
+
+DNS Extensions                                                 R. Arends
+Internet-Draft                                      Telematica Instituut
+Expires: January 13, 2005                                      M. Larson
+                                                                VeriSign
+                                                              R. Austein
+                                                                     ISC
+                                                               D. Massey
+                                                                 USC/ISI
+                                                                 S. Rose
+                                                                    NIST
+                                                           July 15, 2004
+
+
+         Protocol Modifications for the DNS Security Extensions
+                  draft-ietf-dnsext-dnssec-protocol-07
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 13, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document is part of a family of documents which describe the DNS
+   Security Extensions (DNSSEC).  The DNS Security Extensions are a
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 1]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   collection of new resource records and protocol modifications which
+   add data origin authentication and data integrity to the DNS.  This
+   document describes the DNSSEC protocol modifications.  This document
+   defines the concept of a signed zone, along with the requirements for
+   serving and resolving using DNSSEC.  These techniques allow a
+   security-aware resolver to authenticate both DNS resource records and
+   authoritative DNS error indications.
+
+   This document obsoletes RFC 2535 and incorporates changes from all
+   updates to RFC 2535.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1   Background and Related Documents . . . . . . . . . . . . .  4
+     1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     2.1   Including DNSKEY RRs in a Zone . . . . . . . . . . . . . .  5
+     2.2   Including RRSIG RRs in a Zone  . . . . . . . . . . . . . .  5
+     2.3   Including NSEC RRs in a Zone . . . . . . . . . . . . . . .  6
+     2.4   Including DS RRs in a Zone . . . . . . . . . . . . . . . .  7
+     2.5   Changes to the CNAME Resource Record.  . . . . . . . . . .  7
+     2.6   DNSSEC RR Types Appearing at Zone Cuts.  . . . . . . . . .  8
+     2.7   Example of a Secure Zone . . . . . . . . . . . . . . . . .  8
+   3.  Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     3.1   Authoritative Name Servers . . . . . . . . . . . . . . . . 10
+       3.1.1   Including RRSIG RRs in a Response  . . . . . . . . . . 10
+       3.1.2   Including DNSKEY RRs In a Response . . . . . . . . . . 11
+       3.1.3   Including NSEC RRs In a Response . . . . . . . . . . . 11
+       3.1.4   Including DS RRs In a Response . . . . . . . . . . . . 14
+       3.1.5   Responding to Queries for Type AXFR or IXFR  . . . . . 15
+       3.1.6   The AD and CD Bits in an Authoritative Response  . . . 16
+     3.2   Recursive Name Servers . . . . . . . . . . . . . . . . . . 17
+       3.2.1   The DO bit . . . . . . . . . . . . . . . . . . . . . . 17
+       3.2.2   The CD bit . . . . . . . . . . . . . . . . . . . . . . 17
+       3.2.3   The AD bit . . . . . . . . . . . . . . . . . . . . . . 18
+     3.3   Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18
+   4.  Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+     4.1   EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19
+     4.2   Signature Verification Support . . . . . . . . . . . . . . 19
+     4.3   Determining Security Status of Data  . . . . . . . . . . . 20
+     4.4   Configured Trust Anchors . . . . . . . . . . . . . . . . . 20
+     4.5   Response Caching . . . . . . . . . . . . . . . . . . . . . 21
+     4.6   Handling of the CD and AD bits . . . . . . . . . . . . . . 22
+     4.7   Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22
+     4.8   Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23
+     4.9   Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23
+       4.9.1   Handling of the DO Bit . . . . . . . . . . . . . . . . 23
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 2]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+       4.9.2   Handling of the CD Bit . . . . . . . . . . . . . . . . 23
+       4.9.3   Handling of the AD Bit . . . . . . . . . . . . . . . . 24
+   5.  Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
+     5.1   Special Considerations for Islands of Security . . . . . . 26
+     5.2   Authenticating Referrals . . . . . . . . . . . . . . . . . 26
+     5.3   Authenticating an RRset Using an RRSIG RR  . . . . . . . . 27
+       5.3.1   Checking the RRSIG RR Validity . . . . . . . . . . . . 28
+       5.3.2   Reconstructing the Signed Data . . . . . . . . . . . . 28
+       5.3.3   Checking the Signature . . . . . . . . . . . . . . . . 30
+       5.3.4   Authenticating A Wildcard Expanded RRset Positive
+               Response . . . . . . . . . . . . . . . . . . . . . . . 31
+     5.4   Authenticated Denial of Existence  . . . . . . . . . . . . 31
+     5.5   Resolver Behavior When Signatures Do Not Validate  . . . . 32
+     5.6   Authentication Example . . . . . . . . . . . . . . . . . . 32
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
+   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 36
+   9.2   Informative References . . . . . . . . . . . . . . . . . . . 36
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
+   A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 39
+   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 45
+     B.1   Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45
+     B.2   Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46
+     B.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . 47
+     B.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . 48
+     B.5   Referral to Unsigned Zone  . . . . . . . . . . . . . . . . 49
+     B.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50
+     B.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51
+     B.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . 52
+   C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 54
+     C.1   Authenticating An Answer . . . . . . . . . . . . . . . . . 54
+       C.1.1   Authenticating the example DNSKEY RR . . . . . . . . . 54
+     C.2   Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55
+     C.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . 55
+     C.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . 55
+     C.5   Referral to Unsigned Zone  . . . . . . . . . . . . . . . . 55
+     C.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56
+     C.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56
+     C.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . 56
+       Intellectual Property and Copyright Statements . . . . . . . . 57
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 3]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+1.  Introduction
+
+   The DNS Security Extensions (DNSSEC) are a collection of new resource
+   records and protocol modifications which add data origin
+   authentication and data integrity to the DNS.  This document defines
+   the DNSSEC protocol modifications.  Section 2 of this document
+   defines the concept of a signed zone and lists the requirements for
+   zone signing.  Section 3 describes the modifications to authoritative
+   name server behavior necessary to handle signed zones.  Section 4
+   describes the behavior of entities which include security-aware
+   resolver functions.  Finally, Section 5 defines how to use DNSSEC RRs
+   to authenticate a response.
+
+1.1  Background and Related Documents
+
+   The reader is assumed to be familiar with the basic DNS concepts
+   described in [RFC1034] and [RFC1035].
+
+   This document is part of a family of documents that define DNSSEC.
+   An introduction to DNSSEC and definition of common terms can be found
+   in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be
+   familiar with this document.  A definition of the DNSSEC resource
+   records can be found in [I-D.ietf-dnsext-dnssec-records].
+
+1.2  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.  [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 4]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+2.  Zone Signing
+
+   DNSSEC introduces the concept of signed zones.  A signed zone
+   includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
+   the rules specified in Section 2.1, Section 2.2, Section 2.3 and
+   Section 2.4, respectively.  A zone that does not include these
+   records according to the rules in this section is an unsigned zone.
+
+   DNSSEC requires a change to the definition of the CNAME resource
+   record [RFC1035].  Section 2.5 changes the CNAME RR to allow RRSIG
+   and NSEC RRs to appear at the same owner name as a CNAME RR.
+
+   DNSSEC specifies the placement of two new RR types, NSEC and DS,
+   which can be placed at the parental side of a zone cut (that is, at a
+   delegation point).  This is an exception to the general prohibition
+   against putting data in the parent zone at a zone cut.  Section 2.6
+   describes this change.
+
+2.1  Including DNSKEY RRs in a Zone
+
+   To sign a zone, the zone's administrator generates one or more
+   public/private key pairs and uses the private key(s) to sign
+   authoritative RRsets in the zone.  For each private key used to
+   create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
+   containing the corresponding public key.  A zone key DNSKEY RR MUST
+   have the Zone Key bit of the flags RDATA field set -- see Section
+   2.1.1 of [I-D.ietf-dnsext-dnssec-records].  Public keys associated
+   with other DNS operations MAY be stored in DNSKEY RRs that are not
+   marked as zone keys but MUST NOT be used to verify RRSIGs.
+
+   If the zone administrator intends a signed zone to be usable other
+   than as an island of security, the zone apex MUST contain at least
+   one DNSKEY RR to act as a secure entry point into the zone.  This
+   secure entry point could then be used as the target of a secure
+   delegation via a corresponding DS RR in the parent zone (see
+   [I-D.ietf-dnsext-dnssec-records]).
+
+2.2  Including RRSIG RRs in a Zone
+
+   For each authoritative RRset in a signed zone, there MUST be at least
+   one RRSIG record that meets all of the following requirements:
+   o  The RRSIG owner name is equal to the RRset owner name;
+   o  The RRSIG class is equal to the RRset class;
+   o  The RRSIG Type Covered field is equal to the RRset type;
+   o  The RRSIG Original TTL field is equal to the TTL of the RRset;
+   o  The RRSIG RR's TTL is equal to the TTL of the RRset;
+   o  The RRSIG Labels field is equal to the number of labels in the
+      RRset owner name, not counting the null root label and not
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 5]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+      counting the leftmost label if it is a wildcard;
+   o  The RRSIG Signer's Name field is equal to the name of the zone
+      containing the RRset; and
+   o  The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
+      zone key DNSKEY record at the zone apex.
+
+   The process for constructing the RRSIG RR for a given RRset is
+   described in [I-D.ietf-dnsext-dnssec-records].  An RRset MAY have
+   multiple RRSIG RRs associated with it.
+
+   An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
+   would add no value and would create an infinite loop in the signing
+   process.
+
+   The NS RRset that appears at the zone apex name MUST be signed, but
+   the NS RRsets that appear at delegation points (that is, the NS
+   RRsets in the parent zone that delegate the name to the child zone's
+   name servers) MUST NOT be signed.  Glue address RRsets associated
+   with delegations MUST NOT be signed.
+
+   There MUST be an RRSIG for each RRset using at least one DNSKEY of
+   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
+   itself MUST be signed by each algorithm appearing in the DS RRset
+   located at the delegating parent (if any).
+
+2.3  Including NSEC RRs in a Zone
+
+   Each owner name in the zone which has authoritative data or a
+   delegation point NS RRset MUST have an NSEC resource record.  The
+   format of NSEC RRs and the process for constructing the NSEC RR for a
+   given name is described in [I-D.ietf-dnsext-dnssec-records].
+
+   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
+   value field in the zone SOA RR.
+
+   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
+   RRset at any particular owner name.  That is, the signing process
+   MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
+   not the owner name of any RRset before the zone was signed.  The main
+   reasons for this are a desire for namespace consistency between
+   signed and unsigned versions of the same zone and a desire to reduce
+   the risk of response inconsistency in security oblivious recursive
+   name servers.
+
+   The type bitmap of every NSEC resource record in a signed zone MUST
+   indicate the presence of both the NSEC record itself and its
+   corresponding RRSIG record.
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 6]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   The difference between the set of owner names that require RRSIG
+   records and the set of owner names that require NSEC records is
+   subtle and worth highlighting.  RRSIG records are present at the
+   owner names of all authoritative RRsets.  NSEC records are present at
+   the owner names of all names for which the signed zone is
+   authoritative and also at the owner names of delegations from the
+   signed zone to its children.  Neither NSEC nor RRSIG records are
+   present (in the parent zone) at the owner names of glue address
+   RRsets.  Note, however, that this distinction is for the most part is
+   only visible during the zone signing process, because NSEC RRsets are
+   authoritative data, and are therefore signed, thus any owner name
+   which has an NSEC RRset will have RRSIG RRs as well in the signed
+   zone.
+
+   The bitmap for the NSEC RR at a delegation point requires special
+   attention.  Bits corresponding to the delegation NS RRset and any
+   RRsets for which the parent zone has authoritative data MUST be set;
+   bits corresponding to any non-NS RRset for which the parent is not
+   authoritative MUST be clear.
+
+2.4  Including DS RRs in a Zone
+
+   The DS resource record establishes authentication chains between DNS
+   zones.  A DS RRset SHOULD be present at a delegation point when the
+   child zone is signed.  The DS RRset MAY contain multiple records,
+   each referencing a public key in the child zone used to verify the
+   RRSIGs in that zone.  All DS RRsets in a zone MUST be signed and DS
+   RRsets MUST NOT appear at a zone's apex.
+
+   A DS RR SHOULD point to a DNSKEY RR which is present in the child's
+   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
+   by the corresponding private key.
+
+   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
+   (that is, the NS RRset from the same zone containing the DS RRset).
+
+   Construction of a DS RR requires knowledge of the corresponding
+   DNSKEY RR in the child zone, which implies communication between the
+   child and parent zones.  This communication is an operational matter
+   not covered by this document.
+
+2.5  Changes to the CNAME Resource Record.
+
+   If a CNAME RRset is present at a name in a signed zone, appropriate
+   RRSIG and NSEC RRsets are REQUIRED at that name.  A KEY RRset at that
+   name for secure dynamic update purposes is also allowed.  Other types
+   MUST NOT be present at that name.
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 7]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   This is a modification to the original CNAME definition given in
+   [RFC1034].  The original definition of the CNAME RR did not allow any
+   other types to coexist with a CNAME record, but a signed zone
+   requires NSEC and RRSIG RRs for every authoritative name.  To resolve
+   this conflict, this specification modifies the definition of the
+   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
+
+2.6  DNSSEC RR Types Appearing at Zone Cuts.
+
+   DNSSEC introduced two new RR types that are unusual in that they can
+   appear at the parental side of a zone cut.  At the parental side of a
+   zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
+   the owner name.  A DS RR could also be present if the zone being
+   delegated is signed and wishes to have a chain of authentication to
+   the parent zone.  This is an exception to the original DNS
+   specification ([RFC1034]) which states that only NS RRsets could
+   appear at the parental side of a zone cut.
+
+   This specification updates the original DNS specification to allow
+   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
+   are authoritative for the parent when they appear at the parent side
+   of a zone cut.
+
+2.7  Example of a Secure Zone
+
+   Appendix A shows a complete example of a small signed zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 8]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+3.  Serving
+
+   This section describes the behavior of entities that include
+   security-aware name server functions.  In many cases such functions
+   will be part of a security-aware recursive name server, but a
+   security-aware authoritative name server has some of the same
+   requirements.  Functions specific to security-aware recursive name
+   servers are described in Section 3.2; functions specific to
+   authoritative servers are described in Section 3.1.
+
+   The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
+   are as used in [RFC1034].
+
+   A security-aware name server MUST support the EDNS0 [RFC2671] message
+   size extension, MUST support a message size of at least 1220 octets,
+   and SHOULD support a message size of 4000 octets [RFC3226].
+
+   A security-aware name server which receives a DNS query that does not
+   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
+   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset,
+   and MUST NOT perform any of the additional processing described
+   below.  Since the DS RR type has the peculiar property of only
+   existing in the parent zone at delegation points, DS RRs always
+   require some special processing, as described in Section 3.1.4.1.
+
+   Security aware name servers that receive explicit queries for
+   security RR types which match the content of more than one zone that
+   it serves (for example, NSEC and RRSIG RRs above and below a
+   delegation point where the server is authoritative for both zones)
+   should behave self-consistently.  The name server MAY return one of
+   the following:
+   o  The above-delegation RRsets
+   o  The below-delegation RRsets
+   o  Both above and below-delegation RRsets
+   o  Empty answer section (no records)
+   o  Some other response
+   o  An error
+   As long as the response is always consistent for each query to the
+   name server.
+
+   DNSSEC allocates two new bits in the DNS message header: the CD
+   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
+   is controlled by resolvers; a security-aware name server MUST copy
+   the CD bit from a query into the corresponding response.  The AD bit
+   is controlled by name servers; a security-aware name server MUST
+   ignore the setting of the AD bit in queries.  See Section 3.1.6,
+   Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details
+   on the behavior of these bits.
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 9]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   A security aware name server which synthesizes CNAME RRs from DNAME
+   RRs as described in [RFC2672] SHOULD NOT generate signatures for the
+   synthesized CNAME RRs.
+
+3.1  Authoritative Name Servers
+
+   Upon receiving a relevant query that has the EDNS [RFC2671] OPT
+   pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name
+   server for a signed zone MUST include additional RRSIG, NSEC, and DS
+   RRs according to the following rules:
+   o  RRSIG RRs that can be used to authenticate a response MUST be
+      included in the response according to the rules in Section 3.1.1;
+   o  NSEC RRs that can be used to provide authenticated denial of
+      existence MUST be included in the response automatically according
+      to the rules in Section 3.1.3;
+   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
+      be included in referrals automatically according to the rules in
+      Section 3.1.4.
+
+   These rules only apply to responses the semantics of which convey
+   information about the presence or absence of resource records.  That
+   is, these rules are not intended to rule out responses such as RCODE
+   4 ("Not Implemented") or RCODE 5 ("Refused").
+
+   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5
+   discusses zone transfer requirements.
+
+3.1.1  Including RRSIG RRs in a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server SHOULD attempt to send RRSIG RRs that a
+   security-aware resolver can use to authenticate the RRsets in the
+   response.  A name server SHOULD make every attempt to keep the RRset
+   and its associated RRSIG(s) together in a response.  Inclusion of
+   RRSIG RRs in a response is subject to the following rules:
+   o  When placing a signed RRset in the Answer section, the name server
+      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
+      RRs have a higher priority for inclusion than any other RRsets
+      that may need to be included.  If space does not permit inclusion
+      of these RRSIG RRs, the name server MUST set the TC bit.
+   o  When placing a signed RRset in the Authority section, the name
+      server MUST also place its RRSIG RRs in the Authority section.
+      The RRSIG RRs have a higher priority for inclusion than any other
+      RRsets that may need to be included.  If space does not permit
+      inclusion of these RRSIG RRs, the name server MUST set the TC bit.
+   o  When placing a signed RRset in the Additional section, the name
+      server MUST also place its RRSIG RRs in the Additional section.
+      If space does not permit inclusion of both the RRset and its
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 10]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+      associated RRSIG RRs, the name server MAY drop the RRSIG RRs.  If
+      this happens, the name server MUST NOT set the TC bit solely
+      because these RRSIG RRs didn't fit.
+
+3.1.2  Including DNSKEY RRs In a Response
+
+   When responding to a query that has the DO bit set and that requests
+   the SOA or NS RRs at the apex of a signed zone, a security-aware
+   authoritative name server for that zone MAY return the zone apex
+   DNSKEY RRset in the Additional section.  In this situation, the
+   DNSKEY RRset and associated RRSIG RRs have lower priority than any
+   other information that would be placed in the additional section.
+   The name server SHOULD NOT include the DNSKEY RRset unless there is
+   enough space in the response message for both the DNSKEY RRset and
+   its associated RRSIG RR(s).  If there is not enough space to include
+   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
+   NOT set the TC bit solely because these RRs didn't fit (see Section
+   3.1.1).
+
+3.1.3  Including NSEC RRs In a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server for a signed zone MUST include NSEC RRs in
+   each of the following cases:
+
+   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
+      but does not contain any RRsets that exactly match <SNAME, SCLASS,
+      STYPE>.
+
+   Name Error: The zone does not contain any RRsets that match <SNAME,
+      SCLASS> either exactly or via wildcard name expansion.
+
+   Wildcard Answer: The zone does not contain any RRsets that exactly
+      match <SNAME, SCLASS> but does contain an RRset that matches
+      <SNAME, SCLASS, STYPE> via wildcard name expansion.
+
+   Wildcard No Data: The zone does not contain any RRsets that exactly
+      match <SNAME, SCLASS>, does contain one or more RRsets that match
+      <SNAME, SCLASS> via wildcard name expansion, but does not contain
+      any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name
+      expansion.
+
+   In each of these cases, the name server includes NSEC RRs in the
+   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
+   not present in the zone and that the response that the name server is
+   returning is correct given the data that are in the zone.
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 11]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+3.1.3.1  Including NSEC RRs: No Data Response
+
+   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
+   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
+   include the NSEC RR for <SNAME, SCLASS> along with its associated
+   RRSIG RR(s) in the Authority section of the response (see Section
+   3.1.1).  If space does not permit inclusion of the NSEC RR or its
+   associated RRSIG RR(s), the name server MUST set the TC bit (see
+   Section 3.1.1).
+
+   Since the search name exists, wildcard name expansion does not apply
+   to this query, and a single signed NSEC RR suffices to prove the
+   requested RR type does not exist.
+
+3.1.3.2  Including NSEC RRs: Name Error Response
+
+   If the zone does not contain any RRsets matching <SNAME, SCLASS>
+   either exactly or via wildcard name expansion, then the name server
+   MUST include the following NSEC RRs in the Authority section, along
+   with their associated RRSIG RRs:
+   o  An NSEC RR proving that there is no exact match for <SNAME,
+      SCLASS>; and
+   o  An NSEC RR proving that the zone contains no RRsets that would
+      match <SNAME, SCLASS> via wildcard name expansion.
+
+   In some cases a single NSEC RR may prove both of these points, in
+   that case the name server SHOULD only include the NSEC RR and its
+   RRSIG RR(s) once in the Authority section.
+
+   If space does not permit inclusion of these NSEC and RRSIG RRs, the
+   name server MUST set the TC bit (see Section 3.1.1).
+
+   The owner names of these NSEC and RRSIG RRs are not subject to
+   wildcard name expansion when these RRs are included in the Authority
+   section of the response.
+
+   Note that this form of response includes cases in which SNAME
+   corresponds to an empty non-terminal name within the zone (a name
+   which is not the owner name for any RRset but which is the parent
+   name of one or more RRsets).
+
+3.1.3.3  Including NSEC RRs: Wildcard Answer Response
+
+   If the zone does not contain any RRsets which exactly match <SNAME,
+   SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
+   STYPE> via wildcard name expansion, the name server MUST include the
+   wildcard-expanded answer and the corresponding wildcard-expanded
+   RRSIG RRs in the Answer section, and MUST include in the Authority
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 12]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   section an NSEC RR and associated RRSIG RR(s) proving that the zone
+   does not contain a closer match for <SNAME, SCLASS>.  If space does
+   not permit inclusion of the answer, NSEC and RRSIG RRs, the name
+   server MUST set the TC bit (see Section 3.1.1).
+
+3.1.3.4  Including NSEC RRs: Wildcard No Data Response
+
+   This case is a combination of the previous cases.  The zone does not
+   contain an exact match for <SNAME, SCLASS>, and while the zone does
+   contain RRsets which match <SNAME, SCLASS> via wildcard expansion,
+   none of those RRsets match STYPE.  The name server MUST include the
+   following NSEC RRs in the Authority section, along with their
+   associated RRSIG RRs:
+   o  An NSEC RR proving that there are no RRsets matching STYPE at the
+      wildcard owner name which matched <SNAME, SCLASS> via wildcard
+      expansion; and
+   o  An NSEC RR proving that there are no RRsets in the zone which
+      would have been a closer match for <SNAME, SCLASS>.
+
+   In some cases a single NSEC RR may prove both of these points, in
+   which case the name server SHOULD only include the NSEC RR and its
+   RRSIG RR(s) once in the Authority section.
+
+   The owner names of these NSEC and RRSIG RRs are not subject to
+   wildcard name expansion when these RRs are included in the Authority
+   section of the response.
+
+   If space does not permit inclusion of these NSEC and RRSIG RRs, the
+   name server MUST set the TC bit (see Section 3.1.1).
+
+3.1.3.5  Finding The Right NSEC RRs
+
+   As explained above, there are several situations in which a
+   security-aware authoritative name server needs to locate an NSEC RR
+   which proves that no RRsets matching a particular SNAME exist.
+   Locating such an NSEC RR within an authoritative zone is relatively
+   simple, at least in concept.  The following discussion assumes that
+   the name server is authoritative for the zone which would have held
+   the nonexistent RRsets matching SNAME.  The algorithm below is
+   written for clarity, not efficiency.
+
+   To find the NSEC which proves that no RRsets matching name N exist in
+   the zone Z which would have held them, construct sequence S
+   consisting of the owner names of every RRset in Z, sorted into
+   canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate
+   names.  Find the name M which would have immediately preceded N in S
+   if any RRsets with owner name N had existed.  M is the owner name of
+   the NSEC RR which proves that no RRsets exist with owner name N.
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 13]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   The algorithm for finding the NSEC RR which proves that a given name
+   is not covered by any applicable wildcard is similar, but requires an
+   extra step.  More precisely, the algorithm for finding the NSEC
+   proving that no RRsets exist with the applicable wildcard name is
+   precisely the same as the algorithm for finding the NSEC RR which
+   proves that RRsets with any other owner name do not exist: the part
+   that's missing is how to determine the name of the nonexistent
+   applicable wildcard.  In practice, this is easy, because the
+   authoritative name server has already checked for the presence of
+   precisely this wildcard name as part of step (1)(c) of the normal
+   lookup algorithm described in Section 4.3.2 of [RFC1034].
+
+3.1.4  Including DS RRs In a Response
+
+   When responding to a query which has the DO bit set, a security-aware
+   authoritative name server returning a referral includes DNSSEC data
+   along with the NS RRset.
+
+   If a DS RRset is present at the delegation point, the name server
+   MUST return both the DS RRset and its associated RRSIG RR(s) in the
+   Authority section along with the NS RRset.  The name server MUST
+   place the NS RRset before the DS RRset and its associated RRSIG
+   RR(s).
+
+   If no DS RRset is present at the delegation point, the name server
+   MUST return both the NSEC RR which proves that the DS RRset is not
+   present and the NSEC RR's associated RRSIG RR(s) along with the NS
+   RRset.  The name server MUST place the NS RRset before the NSEC RRset
+   and its associated RRSIG RR(s).
+
+   Including these DS, NSEC, and RRSIG RRs increases the size of
+   referral messages, and may cause some or all glue RRs to be omitted.
+   If space does not permit inclusion of the DS or NSEC RRset and
+   associated RRSIG RRs, the name server MUST set the TC bit (see
+   Section 3.1.1).
+
+3.1.4.1  Responding to Queries for DS RRs
+
+   The DS resource record type is unusual in that it appears only on the
+   parent zone's side of a zone cut.  For example, the DS RRset for the
+   delegation of "foo.example" is stored in the "example" zone rather
+   than in the "foo.example" zone.  This requires special processing
+   rules for both name servers and resolvers, since the name server for
+   the child zone is authoritative for the name at the zone cut by the
+   normal DNS rules but the child zone does not contain the DS RRset.
+
+   A security-aware resolver sends queries to the parent zone when
+   looking for a needed DS RR at a delegation point (see Section 4.2).
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 14]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   However, special rules are necessary to avoid confusing
+   security-oblivious resolvers which might become involved in
+   processing such a query (for example, in a network configuration that
+   forces a security-aware resolver to channel its queries through a
+   security-oblivious recursive name server).  The rest of this section
+   describes how a security-aware name server processes DS queries in
+   order to avoid this problem.
+
+   The need for special processing by a security-aware name server only
+   arises when all the following conditions are met:
+   o  the name server has received a query for the DS RRset at a zone
+      cut; and
+   o  the name server is authoritative for the child zone; and
+   o  the name server is not authoritative for the parent zone; and
+   o  the name server does not offer recursion.
+
+   In all other cases, the name server either has some way of obtaining
+   the DS RRset or could not have been expected to have the DS RRset
+   even by the pre-DNSSEC processing rules, so the name server can
+   return either the DS RRset or an error response according to the
+   normal processing rules.
+
+   If all of the above conditions are met, however, the name server is
+   authoritative for SNAME but cannot supply the requested RRset.  In
+   this case, the name server MUST return an authoritative "no data"
+   response showing that the DS RRset does not exist in the child zone's
+   apex.  See Appendix B.8 for an example of such a response.
+
+3.1.5  Responding to Queries for Type AXFR or IXFR
+
+   DNSSEC does not change the DNS zone transfer process.  A signed zone
+   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
+   records have no special meaning with respect to a zone transfer
+   operation.
+
+   An authoritative name server is not required to verify that a zone is
+   properly signed before sending or accepting a zone transfer.
+   However, an authoritative name server MAY choose to reject the entire
+   zone transfer if the zone fails meets any of the signing requirements
+   described in Section 2.  The primary objective of a zone transfer is
+   to ensure that all authoritative name servers have identical copies
+   of the zone.  An authoritative name server that chooses to perform
+   its own zone validation MUST NOT selectively reject some RRs and
+   accept others.
+
+   DS RRsets appear only on the parental side of a zone cut and are
+   authoritative data in the parent zone.  As with any other
+   authoritative RRset, the DS RRset MUST be included in zone transfers
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 15]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   of the zone in which the RRset is authoritative data: in the case of
+   the DS RRset, this is the parent zone.
+
+   NSEC RRs appear in both the parent and child zones at a zone cut, and
+   are authoritative data in both the parent and child zones.  The
+   parental and child NSEC RRs at a zone cut are never identical to each
+   other, since the NSEC RR in the child zone's apex will always
+   indicate the presence of the child zone's SOA RR while the parental
+   NSEC RR at the zone cut will never indicate the presence of an SOA
+   RR.  As with any other authoritative RRs, NSEC RRs MUST be included
+   in zone transfers of the zone in which they are authoritative data:
+   the parental NSEC RR at a zone cut MUST be included zone transfers of
+   the parent zone, while the NSEC at the zone apex of the child zone
+   MUST be included in zone transfers of the child zone.
+
+   RRSIG RRs appear in both the parent and child zones at a zone cut,
+   and are authoritative in whichever zone contains the authoritative
+   RRset for which the RRSIG RR provides the signature.  That is, the
+   RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
+   authoritative in the parent zone, while the RRSIG for any RRset in
+   the child zone's apex will be authoritative in the child zone.
+   Parental and child RRSIG RRs at a zone cut will never be identical to
+   each other, since the Signer's Name field of an RRSIG RR in the child
+   zone's apex will indicate a DNSKEY RR in the child zone's apex while
+   the same field of a parental RRSIG RR at the zone cut will indicate a
+   DNSKEY RR in the parent zone's apex.  As with any other authoritative
+   RRs, RRSIG RRs MUST be included in zone transfers of the zone in
+   which they are authoritative data.
+
+3.1.6  The AD and CD Bits in an Authoritative Response
+
+   The CD and AD bits are designed for use in communication between
+   security-aware resolvers and security-aware recursive name servers.
+   These bits are for the most part not relevant to query processing by
+   security-aware authoritative name servers.
+
+   A security-aware name server does not perform signature validation
+   for authoritative data during query processing even when the CD bit
+   is clear.  A security-aware name server SHOULD clear the CD bit when
+   composing an authoritative response.
+
+   A security-aware name server MUST NOT set the AD bit in a response
+   unless the name server considers all RRsets in the Answer and
+   Authority sections of the response to be authentic.  A security-aware
+   name server's local policy MAY consider data from an authoritative
+   zone to be authentic without further validation, but the name server
+   MUST NOT do so unless the name server obtained the authoritative zone
+   via secure means (such as a secure zone transfer mechanism), and MUST
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 16]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   NOT do so unless this behavior has been configured explicitly.
+
+   A security-aware name server which supports recursion MUST follow the
+   rules for the CD and AD bits given in Section 3.2 when generating a
+   response that involves data obtained via recursion.
+
+3.2  Recursive Name Servers
+
+   As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
+   recursive name server is an entity which acts in both the
+   security-aware name server and security-aware resolver roles.  This
+   section uses the terms "name server side" and "resolver side" to
+   refer to the code within a security-aware recursive name server which
+   implements the security-aware name server role and the code which
+   implements the security-aware resolver role, respectively.
+
+   The resolver side follows the usual rules for caching and negative
+   caching which would apply to any security-aware resolver.
+
+3.2.1  The DO bit
+
+   The resolver side of a security-aware recursive name server MUST set
+   the DO bit when sending requests, regardless of the state of the DO
+   bit in the initiating request received by the name server side.  If
+   the DO bit in an initiating query is not set, the name server side
+   MUST strip any authenticating DNSSEC RRs from the response, but MUST
+   NOT strip any DNSSEC RR types that the initiating query explicitly
+   requested.
+
+3.2.2  The CD bit
+
+   The CD bit exists in order to allow a security-aware resolver to
+   disable signature validation in a security-aware name server's
+   processing of a particular query.
+
+   The name server side MUST copy the setting of the CD bit from a query
+   to the corresponding response.
+
+   The name server side of a security-aware recursive name server MUST
+   pass the sense of the CD bit to the resolver side along with the rest
+   of an initiating query, so that the resolver side will know whether
+   or not it is required to verify the response data it returns to the
+   name server side.  If the CD bit is set, it indicates that the
+   originating resolver is willing to perform whatever authentication
+   its local policy requires, thus the resolver side of the recursive
+   name server need not perform authentication on the RRsets in the
+   response.  When the CD bit is set the recursive name server SHOULD,
+   if possible, return the requested data to the originating resolver
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 17]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   even if the recursive name server's local authentication policy would
+   reject the records in question.  That is, by setting the CD bit, the
+   originating resolver has indicated that it takes responsibility for
+   performing its own authentication, and the recursive name server
+   should not interfere.
+
+   If the resolver side implements a BAD cache (see Section 4.7) and the
+   name server side receives a query which matches an entry in the
+   resolver side's BAD cache, the name server side's response depends on
+   the sense of the CD bit in the original query.  If the CD bit is set,
+   the name server side SHOULD return the data from the BAD cache; if
+   the CD bit is not set, the name server side MUST return RCODE 2
+   (server failure).
+
+   The intent of the above rule is to provide the raw data to clients
+   which are capable of performing their own signature verification
+   checks while protecting clients which depend on the resolver side of
+   a security-aware recursive name server to perform such checks.
+   Several of the possible reasons why signature validation might fail
+   involve conditions which may not apply equally to the recursive name
+   server and the client which invoked it: for example, the recursive
+   name server's clock may be set incorrectly, or the client may have
+   knowledge of a relevant island of security which the recursive name
+   server does not share.  In such cases, "protecting" a client which is
+   capable of performing its own signature validation from ever seeing
+   the "bad" data does not help the client.
+
+3.2.3  The AD bit
+
+   The name server side of a security-aware recursive name server MUST
+   NOT set the AD bit in a response unless the name server considers all
+   RRsets in the Answer and Authority sections of the response to be
+   authentic.  The name server side SHOULD set the AD bit if and only if
+   the resolver side considers all RRsets in the Answer section and any
+   relevant negative response RRs in the Authority section to be
+   authentic.  The resolver side MUST follow the procedure described in
+   Section 5 to determine whether the RRs in question are authentic.
+   However, for backwards compatibility, a recursive name server MAY set
+   the AD bit when a response includes unsigned CNAME RRs if those CNAME
+   RRs demonstrably could have been synthesized from an authentic DNAME
+   RR which is also included in the response according to the synthesis
+   rules described in [RFC2672].
+
+3.3  Example DNSSEC Responses
+
+   See Appendix B for example response packets.
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 18]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+4.  Resolving
+
+   This section describes the behavior of entities that include
+   security-aware resolver functions.  In many cases such functions will
+   be part of a security-aware recursive name server, but a stand-alone
+   security-aware resolver has many of the same requirements.  Functions
+   specific to security-aware recursive name servers are described in
+   Section 3.2.
+
+4.1  EDNS Support
+
+   A security-aware resolver MUST include an EDNS [RFC2671] OPT
+   pseudo-RR with the DO [RFC3225] bit set when sending queries.
+
+   A security-aware resolver MUST support a message size of at least
+   1220 octets, SHOULD support a message size of 4000 octets, and MUST
+   advertise the supported message size using the "sender's UDP payload
+   size" field in the EDNS OPT pseudo-RR.  A security-aware resolver
+   MUST handle fragmented UDP packets correctly regardless of whether
+   any such fragmented packets were received via IPv4 or IPv6.  Please
+   see [RFC3226] for discussion of these requirements.
+
+4.2  Signature Verification Support
+
+   A security-aware resolver MUST support the signature verification
+   mechanisms described in Section 5, and SHOULD apply them to every
+   received response except when:
+   o  The security-aware resolver is part of a security-aware recursive
+      name server, and the response is the result of recursion on behalf
+      of a query received with the CD bit set;
+   o  The response is the result of a query generated directly via some
+      form of application interface which instructed the security-aware
+      resolver not to perform validation for this query; or
+   o  Validation for this query has been disabled by local policy.
+
+   A security-aware resolver's support for signature verification MUST
+   include support for verification of wildcard owner names.
+
+   Security aware resolvers MAY query for missing security RRs in an
+   attempt to perform validation; implementations that choose to do so
+   must be aware that the answers received may not be sufficient to
+   validate the original response.
+
+   When attempting to retrieve missing NSEC RRs which reside on the
+   parental side at a zone cut, a security-aware iterative-mode resolver
+   MUST query the name servers for the parent zone, not the child zone.
+
+   When attempting to retrieve a missing DS, a security-aware
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 19]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   iterative-mode resolver MUST query the name servers for the parent
+   zone, not the child zone.  As explained in Section 3.1.4.1,
+   security-aware name servers need to apply special processing rules to
+   handle the DS RR, and in some situations the resolver may also need
+   to apply special rules to locate the name servers for the parent zone
+   if the resolver does not already have the parent's NS RRset.  To
+   locate the parent NS RRset, the resolver can start with the
+   delegation name, strip off the leftmost label, and query for an NS
+   RRset by that name; if no NS RRset is present at that name, the
+   resolver then strips of the leftmost remaining label and retries the
+   query for that name, repeating this process of walking up the tree
+   until it either finds the NS RRset or runs out of labels.
+
+4.3  Determining Security Status of Data
+
+   A security-aware resolver MUST be able to determine whether or not it
+   should expect a particular RRset to be signed.  More precisely, a
+   security-aware resolver must be able to distinguish between four
+   cases:
+
+   Secure: An RRset for which the resolver is able to build a chain of
+      signed DNSKEY and DS RRs from a trusted security anchor to the
+      RRset.  In this case, the RRset should be signed, and is subject
+      to signature validation as described above.
+
+   Insecure: An RRset for which the resolver knows that it has no chain
+      of signed DNSKEY and DS RRs from any trusted starting point to the
+      RRset.  This can occur when the target RRset lies in an unsigned
+      zone or in a descendent of an unsigned zone.  In this case, the
+      RRset may or may not be signed, but the resolver will not be able
+      to verify the signature.
+
+   Bogus: An RRset for which the resolver believes that it ought to be
+      able to establish a chain of trust but is unable to do so, either
+      due to signatures that for some reason fail to validate or due to
+      missing data which the relevant DNSSEC RRs indicate should be
+      present.  This case may indicate an attack, but may also indicate
+      a configuration error or some form of data corruption.
+
+   Indeterminate: An RRset for which the resolver is not able to
+      determine whether or not the RRset should be signed, because the
+      resolver is not able to obtain the necessary DNSSEC RRs.  This can
+      occur when the security-aware resolver is not able to contact
+      security-aware name servers for the relevant zones.
+
+4.4  Configured Trust Anchors
+
+   A security-aware resolver MUST be capable of being configured with at
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 20]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   least one trusted public key or DS RR, and SHOULD be capable of being
+   configured with multiple trusted public keys or DS RRs.  Since a
+   security-aware resolver will not be able to validate signatures
+   without such a configured trust anchor, the resolver SHOULD have some
+   reasonably robust mechanism for obtaining such keys when it boots;
+   examples of such a mechanism would be some form of non-volatile
+   storage (such as a disk drive) or some form of trusted local network
+   configuration mechanism.
+
+   Note that trust anchors also covers key material that is updated in a
+   secure manner.  This secure manner could be through physical media, a
+   key exchange protocol, or some other out of band means.
+
+4.5  Response Caching
+
+   A security-aware resolver SHOULD cache each response as a single
+   atomic entry containing the entire answer, including the named RRset
+   and any associated DNSSEC RRs.  The resolver SHOULD discard the
+   entire atomic entry when any of the RRs contained in it expire.  In
+   most cases the appropriate cache index for the atomic entry will be
+   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
+   form described in Section 3.1.3.2 the appropriate cache index will be
+   the double <QNAME,QCLASS>.
+
+   The reason for these recommendations is that, between the initial
+   query and the expiration of the data from the cache, the
+   authoritative data might have been changed (for example, via dynamic
+   update).
+
+   There are two situations for which this is relevant:
+   1.  By using the RRSIG record, it is possible to deduce that an
+       answer was synthesized from a wildcard.  A security aware
+       recursive name server could store this wildcard data and use it
+       to generate positive responses to queries other than the name for
+       which the original answer was first received.
+   2.  NSEC RRs received to prove the non-existence of a name could be
+       reused by a security aware resolver to prove the non-existence of
+       any name in the name range it spans.
+
+   In theory, a resolver could use wildcards or NSEC RRs to generate
+   positive and negative responses (respectively) until the TTL or
+   signatures on the records in question expire.  However, it seems
+   prudent for resolvers to avoid blocking new authoritative data or
+   synthesizing new data on their own.  Resolvers which follow this
+   recommendation will have a more consistent view of the namespace.
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 21]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+4.6  Handling of the CD and AD bits
+
+   A security-aware resolver MAY set a query's CD bit in order to
+   indicate that the resolver takes responsibility for performing
+   whatever authentication its local policy requires on the RRsets in
+   the response.  See Section 3.2 for the effect this bit has on the
+   behavior of security-aware recursive name servers.
+
+   A security-aware resolver MUST clear the AD bit when composing query
+   messages to protect against buggy name servers which blindly copy
+   header bits which they do not understand from the query message to
+   the response message.
+
+   A resolver MUST disregard the meaning of the CD and AD bits in a
+   response unless the response was obtained using a secure channel or
+   the resolver was specifically configured to regard the message header
+   bits without using a secure channel.
+
+4.7  Caching BAD Data
+
+   While many validation errors will be transient, some are likely to be
+   more persistent, such as those caused by administrative error
+   (failure to re-sign a zone, clock skew, and so forth).  Since
+   requerying will not help in these cases, validating resolvers might
+   generate a significant amount of unnecessary DNS traffic as a result
+   of repeated queries for RRsets with persistent validation failures.
+
+   To prevent such unnecessary DNS traffic, security-aware resolvers MAY
+   cache data with invalid signatures, with some restrictions.
+   Conceptually, caching such data is similar to negative caching
+   [RFC2308], except that instead of caching a valid negative response,
+   the resolver is caching the fact that a particular answer failed to
+   validate.  This document refers to a cache of data with invalid
+   signatures as a "BAD cache".
+
+   Resolvers which implement a BAD cache MUST take steps to prevent the
+   cache from being useful as a denial-of-service attack amplifier.  In
+   particular:
+   o  Since RRsets which fail to validate do not have trustworthy TTLs,
+      the implementation MUST assign a TTL.  This TTL SHOULD be small,
+      in order to mitigate the effect of caching the results of an
+      attack.
+   o  In order to prevent caching of a transient validation failure
+      (which might be the result of an attack), resolvers SHOULD track
+      queries that result in validation failures, and SHOULD only answer
+      from the BAD cache after the number of times that responses to
+      queries for that particular <QNAME, QTYPE, QCLASS> have failed to
+      validate exceeds a threshold value.
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 22]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   Resolvers MUST NOT return RRsets from the BAD cache unless the
+   resolver is not required to validate the signatures of the RRsets in
+   question under the rules given in Section 4.2 of this document.  See
+   Section 3.2.2 for discussion of how the responses returned by a
+   security-aware recursive name server interact with a BAD cache.
+
+4.8  Synthesized CNAMEs
+
+   A validating security-aware resolver MUST treat the signature of a
+   valid signed DNAME RR as also covering unsigned CNAME RRs which could
+   have been synthesized from the DNAME RR as described in [RFC2672], at
+   least to the extent of not rejecting a response message solely
+   because it contains such CNAME RRs.  The resolver MAY retain such
+   CNAME RRs in its cache or in the answers it hands back, but is not
+   required to do so.
+
+4.9  Stub resolvers
+
+   A security-aware stub resolver MUST support the DNSSEC RR types, at
+   least to the extent of not mishandling responses just because they
+   contain DNSSEC RRs.
+
+4.9.1  Handling of the DO Bit
+
+   A non-validating security-aware stub resolver MAY include the DNSSEC
+   RRs returned by a security-aware recursive name server as part of the
+   data that the stub resolver hands back to the application which
+   invoked it but is not required to do so.  A non-validating stub
+   resolver that wishes to do this will need to set the DO bit in
+   receive DNSSEC RRs from the recursive name server.
+
+   A validating security-aware stub resolver MUST set the DO bit, since
+   otherwise it will not receive the DNSSEC RRs it needs to perform
+   signature validation.
+
+4.9.2  Handling of the CD Bit
+
+   A non-validating security-aware stub resolver SHOULD NOT set the CD
+   bit when sending queries unless requested by the application layer,
+   since by definition, a non-validating stub resolver depends on the
+   security-aware recursive name server to perform validation on its
+   behalf.
+
+   A validating security-aware stub resolver SHOULD set the CD bit,
+   since otherwise the security-aware recursive name server will answer
+   the query using the name server's local policy, which may prevent the
+   stub resolver from receiving data which would be acceptable to the
+   stub resolver's local policy.
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 23]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+4.9.3  Handling of the AD Bit
+
+   A non-validating security-aware stub resolver MAY chose to examine
+   the setting of the AD bit in response messages that it receives in
+   order to determine whether the security-aware recursive name server
+   which sent the response claims to have cryptographically verified the
+   data in the Answer and Authority sections of the response message.
+   Note, however, that the responses received by a security-aware stub
+   resolver are heavily dependent on the local policy of the
+   security-aware recursive name server, so as a practical matter there
+   may be little practical value to checking the status of the AD bit
+   except perhaps as a debugging aid.  In any case, a security-aware
+   stub resolver MUST NOT place any reliance on signature validation
+   allegedly performed on its behalf except when the security-aware stub
+   resolver obtained the data in question from a trusted security-aware
+   recursive name server via a secure channel.
+
+   A validating security-aware stub resolver SHOULD NOT examine the
+   setting of the AD bit in response messages, since, by definition, the
+   stub resolver performs its own signature validation regardless of the
+   setting of the AD bit.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 24]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+5.  Authenticating DNS Responses
+
+   In order to use DNSSEC RRs for authentication, a security-aware
+   resolver requires configured knowledge of at least one authenticated
+   DNSKEY or DS RR.  The process for obtaining and authenticating this
+   initial trust anchors is achieved via some external mechanism.  For
+   example, a resolver could use some off-line authenticated exchange to
+   obtain a zone's DNSKEY RR or obtain a DS RR that identifies and
+   authenticates a zone's DNSKEY RR.  The remainder of this section
+   assumes that the resolver has somehow obtained an initial set of
+   trust anchors.
+
+   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
+   RRset.  To authenticate an apex DNSKEY RRset using an initial key,
+   the resolver MUST:
+   1.  Verify that the initial DNSKEY RR appears in the apex DNSKEY
+       RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
+       (DNSKEY RDATA bit 7) set.
+   2.  Verify that there is some RRSIG RR that covers the apex DNSKEY
+       RRset, and that the combination of the RRSIG RR and the initial
+       DNSKEY RR authenticates the DNSKEY RRset.  The process for using
+       an RRSIG RR to authenticate an RRset is described in Section 5.3.
+
+   Once the resolver has authenticated the apex DNSKEY RRset using an
+   initial DNSKEY RR, delegations from that zone can be authenticated
+   using DS RRs.  This allows a resolver to start from an initial key,
+   and use DS RRsets to proceed recursively down the DNS tree obtaining
+   other apex DNSKEY RRsets.  If the resolver were configured with a
+   root DNSKEY RR, and if every delegation had a DS RR associated with
+   it, then the resolver could obtain and validate any apex DNSKEY
+   RRset.  The process of using DS RRs to authenticate referrals is
+   described in Section 5.2.
+
+   Once the resolver has authenticated a zone's apex DNSKEY RRset,
+   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
+   DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
+   RRsets in the zone.  Section 5.4 shows how the resolver can use
+   authenticated NSEC RRsets from the zone to prove that an RRset is not
+   present in the zone.
+
+   When a resolver indicates support for DNSSEC (by setting the DO bit),
+   a security-aware name server should attempt to provide the necessary
+   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
+   However, a security-aware resolver may still receive a response that
+   that lacks the appropriate DNSSEC RRs, whether due to configuration
+   issues such as an upstream security-oblivious recursive name server
+   that accidentally interferes with DNSSEC RRs or due to a deliberate
+   attack in which an adversary forges a response, strips DNSSEC RRs
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 25]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   from a response, or modifies a query so that DNSSEC RRs appear not to
+   be requested.  The absence of DNSSEC data in a response MUST NOT by
+   itself be taken as an indication that no authentication information
+   exists.
+
+   A resolver SHOULD expect authentication information from signed
+   zones.  A resolver SHOULD believe that a zone is signed if the
+   resolver has been configured with public key information for the
+   zone, or if the zone's parent is signed and the delegation from the
+   parent contains a DS RRset.
+
+5.1  Special Considerations for Islands of Security
+
+   Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
+   zones for which it is not possible to construct an authentication
+   chain to the zone from its parent.  Validating signatures within an
+   island of security requires the validator to have some other means of
+   obtaining an initial authenticated zone key for the island.  If a
+   validator cannot obtain such a key, it SHOULD switch to operating as
+   if the zones in the island of security are unsigned.
+
+   All the normal processes for validating responses apply to islands of
+   security.  The only difference between normal validation and
+   validation within an island of security is in how the validator
+   obtains a trust anchor for the authentication chain.
+
+5.2  Authenticating Referrals
+
+   Once the apex DNSKEY RRset for a signed parent zone has been
+   authenticated, DS RRsets can be used to authenticate the delegation
+   to a signed child zone.  A DS RR identifies a DNSKEY RR in the child
+   zone's apex DNSKEY RRset, and contains a cryptographic digest of the
+   child zone's DNSKEY RR.  A strong cryptographic digest algorithm
+   ensures that an adversary can not easily generate a DNSKEY RR that
+   matches the digest.  Thus, authenticating the digest allows a
+   resolver to authenticate the matching DNSKEY RR.  The resolver can
+   then use this child DNSKEY RR to authenticate the entire child apex
+   DNSKEY RRset.
+
+   Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
+   can be authenticated if all of the following hold:
+   o  The DS RR has been authenticated using some DNSKEY RR in the
+      parent's apex DNSKEY RRset (see Section 5.3);
+   o  The Algorithm and Key Tag in the DS RR match the Algorithm field
+      and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
+      RRset and, when hashed using the digest algorithm specified in the
+      DS RR's Digest Type field, results in a digest value that matches
+      the Digest field of the DS RR; and
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 26]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   o  The matching DNSKEY RR in the child zone has the Zone Flag bit
+      set, the corresponding private key has signed the child zone's
+      apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
+      child zone's apex DNSKEY RRset.
+
+   If the referral from the parent zone did not contain a DS RRset, the
+   response should have included a signed NSEC RRset proving that no DS
+   RRset exists for the delegated name (see Section 3.1.4).  A
+   security-aware resolver MUST query the name servers for the parent
+   zone for the DS RRset if the referral includes neither a DS RRset nor
+   a NSEC RRset proving that the DS RRset does not exist (see Section
+   4).
+
+   If the validator authenticates an NSEC RRset that proves that no DS
+   RRset is present for this zone, then there is no authentication path
+   leading from the parent to the child.  If the resolver has an initial
+   DNSKEY or DS RR that belongs to the child zone or to any delegation
+   below the child zone, this initial DNSKEY or DS RR MAY be used to
+   re-establish an authentication path.  If no such initial DNSKEY or DS
+   RR exists, the validator can not authenticate RRsets in or below the
+   child zone.
+
+   If the validator does not support any of the algorithms listed in an
+   authenticated DS RRset, then the resolver has no supported
+   authentication path leading from the parent to the child.  The
+   resolver should treat this case as it would the case of an
+   authenticated NSEC RRset proving that no DS RRset exists, as
+   described above.
+
+   Note that, for a signed delegation, there are two NSEC RRs associated
+   with the delegated name.  One NSEC RR resides in the parent zone, and
+   can be used to prove whether a DS RRset exists for the delegated
+   name.  The second NSEC RR resides in the child zone, and identifies
+   which RRsets are present at the apex of the child zone.  The parent
+   NSEC RR and child NSEC RR can always be distinguished, since the SOA
+   bit will be set in the child NSEC RR and clear in the parent NSEC RR.
+   A security-aware resolver MUST use the parent NSEC RR when attempting
+   to prove that a DS RRset does not exist.
+
+   If the resolver does not support any of the algorithms listed in an
+   authenticated DS RRset, then the resolver will not be able to verify
+   the authentication path to the child zone.  In this case, the
+   resolver SHOULD treat the child zone as if it were unsigned.
+
+5.3  Authenticating an RRset Using an RRSIG RR
+
+   A validator can use an RRSIG RR and its corresponding DNSKEY RR to
+   attempt to authenticate RRsets.  The validator first checks the RRSIG
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 27]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   RR to verify that it covers the RRset, has a valid time interval, and
+   identifies a valid DNSKEY RR.  The validator then constructs the
+   canonical form of the signed data by appending the RRSIG RDATA
+   (excluding the Signature Field) with the canonical form of the
+   covered RRset.  Finally, the validator uses the public key and
+   signature to authenticate the signed data.  Section 5.3.1, Section
+   5.3.2, and Section 5.3.3 describe each step in detail.
+
+5.3.1  Checking the RRSIG RR Validity
+
+   A security-aware resolver can use an RRSIG RR to authenticate an
+   RRset if all of the following conditions hold:
+   o  The RRSIG RR and the RRset MUST have the same owner name and the
+      same class;
+   o  The RRSIG RR's Signer's Name field MUST be the name of the zone
+      that contains the RRset;
+   o  The RRSIG RR's Type Covered field MUST equal the RRset's type;
+   o  The number of labels in the RRset owner name MUST be greater than
+      or equal to the value in the RRSIG RR's Labels field;
+   o  The validator's notion of the current time MUST be less than or
+      equal to the time listed in the RRSIG RR's Expiration field;
+   o  The validator's notion of the current time MUST be greater than or
+      equal to the time listed in the RRSIG RR's Inception field;
+   o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
+      match the owner name, algorithm, and key tag for some DNSKEY RR in
+      the zone's apex DNSKEY RRset;
+   o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
+      RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
+      set.
+
+   It is possible for more than one DNSKEY RR to match the conditions
+   above.  In this case, the validator cannot predetermine which DNSKEY
+   RR to use to authenticate the signature, MUST try each matching
+   DNSKEY RR until either the signature is validated or the validator
+   has run out of matching public keys to try.
+
+   Note that this authentication process is only meaningful if the
+   validator authenticates the DNSKEY RR before using it to validate
+   signatures.  The matching DNSKEY RR is considered to be authentic if:
+   o  The apex DNSKEY RRset containing the DNSKEY RR is considered
+      authentic; or
+   o  The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
+      and the DNSKEY RR either matches an authenticated DS RR from the
+      parent zone or matches a trust anchor.
+
+5.3.2  Reconstructing the Signed Data
+
+   Once the RRSIG RR has met the validity requirements described in
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 28]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   Section 5.3.1, the validator needs to reconstruct the original signed
+   data.  The original signed data includes RRSIG RDATA (excluding the
+   Signature field) and the canonical form of the RRset.  Aside from
+   being ordered, the canonical form of the RRset might also differ from
+   the received RRset due to DNS name compression, decremented TTLs, or
+   wildcard expansion.  The validator should use the following to
+   reconstruct the original signed data:
+
+         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where
+
+            "|" denotes concatenation
+
+            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+               with the Signature field excluded and the Signer's Name
+               in canonical form.
+
+            RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
+
+               name is calculated according to the function below
+
+               class is the RRset's class
+
+               type is the RRset type and all RRs in the class
+
+               OrigTTL is the value from the RRSIG Original TTL field
+
+               All names in the RDATA field are in canonical form
+
+               The set of all RR(i) is sorted into canonical order.
+
+            To calculate the name:
+               let rrsig_labels = the value of the RRSIG Labels field
+
+               let fqdn = RRset's fully qualified domain name in
+                               canonical form
+
+               let fqdn_labels = Label count of the fqdn above.
+
+               if rrsig_labels = fqdn_labels,
+                   name = fqdn
+
+               if rrsig_labels < fqdn_labels,
+                  name = "*." | the rightmost rrsig_label labels of the
+                                fqdn
+
+               if rrsig_labels > fqdn_labels
+                  the RRSIG RR did not pass the necessary validation
+                  checks and MUST NOT be used to authenticate this
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 29]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+                  RRset.
+
+   The canonical forms for names and RRsets are defined in
+   [I-D.ietf-dnsext-dnssec-records].
+
+   NSEC RRsets at a delegation boundary require special processing.
+   There are two distinct NSEC RRsets associated with a signed delegated
+   name.  One NSEC RRset resides in the parent zone, and specifies which
+   RRset are present at the parent zone.  The second NSEC RRset resides
+   at the child zone, and identifies which RRsets are present at the
+   apex in the child zone.  The parent NSEC RRset and child NSEC RRset
+   can always be distinguished since only the child NSEC RRs will
+   specify an SOA RRset exists at the name.  When reconstructing the
+   original NSEC RRset for the delegation from the parent zone, the NSEC
+   RRs MUST NOT be combined with NSEC RRs from the child zone, and when
+   reconstructing the original NSEC RRset for the apex of the child
+   zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
+   zone.
+
+   Note also that each of the two NSEC RRsets at a delegation point has
+   a corresponding RRSIG RR with an owner name matching the delegated
+   name, and each of these RRSIG RRs is authoritative data associated
+   with the same zone that contains the corresponding NSEC RRset.  If
+   necessary, a resolver can tell these RRSIG RRs apart by checking the
+   Signer's Name field.
+
+5.3.3  Checking the Signature
+
+   Once the resolver has validated the RRSIG RR as described in Section
+   5.3.1 and reconstructed the original signed data as described in
+   Section 5.3.2, the validator can attempt to use the cryptographic
+   signature to authenticate the signed data, and thus (finally!)
+   authenticate the RRset.
+
+   The Algorithm field in the RRSIG RR identifies the cryptographic
+   algorithm used to generate the signature.  The signature itself is
+   contained in the Signature field of the RRSIG RDATA, and the public
+   key used to verify the signature is contained in the Public Key field
+   of the matching DNSKEY RR(s) (found in Section 5.3.1).
+   [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types
+   and provides pointers to the documents that define each algorithm's
+   use.
+
+   Note that it is possible for more than one DNSKEY RR to match the
+   conditions in Section 5.3.1.  In this case, the validator can only
+   determine which DNSKEY RR by trying each matching public key until
+   the validator either succeeds in validating the signature or runs out
+   of keys to try.
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 30]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   If the Labels field of the RRSIG RR is not equal to the number of
+   labels in the RRset's fully qualified owner name, then the RRset is
+   either invalid or the result of wildcard expansion.  The resolver
+   MUST verify that wildcard expansion was applied properly before
+   considering the RRset to be authentic.  Section 5.3.4 describes how
+   to determine whether a wildcard was applied properly.
+
+   If other RRSIG RRs also cover this RRset, the local resolver security
+   policy determines whether the resolver also needs to test these RRSIG
+   RRs, and determines how to resolve conflicts if these RRSIG RRs lead
+   to differing results.
+
+   If the resolver accepts the RRset as authentic, the validator MUST
+   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
+   a value no greater than the minimum of:
+   o  The RRset's TTL as received in the response;
+   o  The RRSIG RR's TTL as received in the response;
+   o  The value in the RRSIG RR's Original TTL field; and
+   o  The difference of the RRSIG RR's Signature Expiration time and the
+      current time.
+
+5.3.4  Authenticating A Wildcard Expanded RRset Positive Response
+
+   If the number of labels in an RRset's owner name is greater than the
+   Labels field of the covering RRSIG RR, then the RRset and its
+   covering RRSIG RR were created as a result of wildcard expansion.
+   Once the validator has verified the signature as described in Section
+   5.3, it must take additional steps to verify the non-existence of an
+   exact match or closer wildcard match for the query.  Section 5.4
+   discusses these steps.
+
+   Note that the response received by the resolver should include all
+   NSEC RRs needed to authenticate the response (see Section 3.1.3).
+
+5.4  Authenticated Denial of Existence
+
+   A resolver can use authenticated NSEC RRs to prove that an RRset is
+   not present in a signed zone.  Security-aware name servers should
+   automatically include any necessary NSEC RRs for signed zones in
+   their responses to security-aware resolvers.
+
+   Denial of existence is determined by the following rules:
+   o  If the requested RR name matches the owner name of an
+      authenticated NSEC RR, then the NSEC RR's type bit map field lists
+      all RR types present at that owner name, and a resolver can prove
+      that the requested RR type does not exist by checking for the RR
+      type in the bit map.  If the number of labels in an authenticated
+      NSEC RR's owner name equals the Labels field of the covering RRSIG
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 31]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+      RR, then the existence of the NSEC RR proves that wildcard
+      expansion could not have been used to match the request.
+   o  If the requested RR name would appear after an authenticated NSEC
+      RR's owner name and before the name listed in that NSEC RR's Next
+      Domain Name field according to the canonical DNS name order
+      defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
+      the requested name exist in the zone.  However, it is possible
+      that a wildcard could be used to match the requested RR owner name
+      and type, so proving that the requested RRset does not exist also
+      requires proving that no possible wildcard RRset exists that could
+      have been used to generate a positive response.
+
+   In addition, security-aware resolvers MUST authenticate the NSEC
+   RRsets that comprise the non-existence proof as described in Section
+   5.3.
+
+   To prove non-existence of an RRset, the resolver must be able to
+   verify both that the queried RRset does not exist and that no
+   relevant wildcard RRset exists.  Proving this may require more than
+   one NSEC RRset from the zone.  If the complete set of necessary NSEC
+   RRsets is not present in a response (perhaps due to message
+   truncation), then a security-aware resolver MUST resend the query in
+   order to attempt to obtain the full collection of NSEC RRs necessary
+   to verify non-existence of the requested RRset.  As with all DNS
+   operations, however, the resolver MUST bound the work it puts into
+   answering any particular query.
+
+   Since a validated NSEC RR proves the existence of both itself and its
+   corresponding RRSIG RR, a validator MUST ignore the settings of the
+   NSEC and RRSIG bits in an NSEC RR.
+
+5.5  Resolver Behavior When Signatures Do Not Validate
+
+   If for whatever reason none of the RRSIGs can be validated, the
+   response SHOULD be considered BAD.  If the validation was being done
+   to service a recursive query, the name server MUST return RCODE 2 to
+   the originating client.  However, it MUST return the full response if
+   and only if the original query had the CD bit set.  See also Section
+   4.7 on caching responses that do not validate.
+
+5.6  Authentication Example
+
+   Appendix C shows an example the authentication process.
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 32]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+6.  IANA Considerations
+
+   [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
+   considerations introduced by DNSSEC.  The additional IANA
+   considerations discussed in this document:
+
+   [RFC2535] reserved the CD and AD bits in the message header.  The
+   meaning of the AD bit was redefined in [RFC3655] and the meaning of
+   both the CD and AD bit are restated in this document.  No new bits in
+   the DNS message header are defined in this document.
+
+   [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
+   and defined its use.  The use is restated but not altered in this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 33]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+7.  Security Considerations
+
+   This document describes how the DNS security extensions use public
+   key cryptography to sign and authenticate DNS resource record sets.
+   Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
+   security considerations related to DNSSEC; see
+   [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the
+   DNSSEC resource record types.
+
+   An active attacker who can set the CD bit in a DNS query message or
+   the AD bit in a DNS response message can use these bits to defeat the
+   protection which DNSSEC attempts to provide to security-oblivious
+   recursive-mode resolvers.  For this reason, use of these control bits
+   by a security-aware recursive-mode resolver requires a secure
+   channel.  See Section 3.2.2 and Section 4.9 for further discussion.
+
+   The protocol described in this document attempts to extend the
+   benefits of DNSSEC to security-oblivious stub resolvers.  However,
+   since recovery from validation failures is likely to be specific to
+   particular applications, the facilities that DNSSEC provides for stub
+   resolvers may prove inadequate.  Operators of security-aware
+   recursive name servers will need to pay close attention to the
+   behavior of the applications which use their services when choosing a
+   local validation policy; failure to do so could easily result in the
+   recursive name server accidentally denying service to the clients it
+   is intended to support.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 34]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+8.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group and working group mailing list.  The
+   editors would like to express their thanks for the comments and
+   suggestions received during the revision of these security extension
+   specifications.  While explicitly listing everyone who has
+   contributed during the decade during which DNSSEC has been under
+   development would be an impossible task,
+   [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
+   participants who were kind enough to comment on these documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 35]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+9.  References
+
+9.1  Normative References
+
+   [I-D.ietf-dnsext-dnssec-intro]
+              Arends, R., Austein, R., Larson, M., Massey, D. and S.
+              Rose, "DNS Security Introduction and Requirements",
+              draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
+              2004.
+
+   [I-D.ietf-dnsext-dnssec-records]
+              Arends, R., Austein, R., Larson, M., Massey, D. and S.
+              Rose, "Resource Records for DNS Security Extensions",
+              draft-ietf-dnsext-dnssec-records-08 (work in progress),
+              May 2004.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              August 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+              2672, August 1999.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226, December 2001.
+
+9.2  Informative References
+
+   [I-D.ietf-dnsext-nsec-rdata]
+              Schlyter, J., "DNSSEC NSEC RDATA Format",
+              draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 36]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+              2004.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
+              SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+              Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Drienerlolaan 5
+   7522 NB  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 37]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   Dan Massey
+   USC Information Sciences Institute
+   3811 N. Fairfax Drive
+   Arlington, VA  22203
+   USA
+
+   EMail: masseyd@isi.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 38]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+Appendix A.  Signed Zone Example
+
+   The following example shows a (small) complete signed zone.
+
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+                  3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+                  3600 NS     ns1.example.
+                  3600 NS     ns2.example.
+                  3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+                  3600 MX     1 xx.example.
+                  3600 RRSIG  MX 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
+                              2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
+                              VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
+                              6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
+                              W6OISukd1EQt7a0kygkg+PEDxdI= )
+                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+                  3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+                  3600 DNSKEY 256 3 5 (
+                              AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
+                              rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
+                              k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
+                              vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 39]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+                              ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
+                              )
+                  3600 DNSKEY 257 3 5 (
+                              AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
+                              LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
+                              syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
+                              RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
+                              Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
+                              )
+                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
+                              20040409183619 9465 example.
+                              ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
+                              xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
+                              XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
+                              hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
+                              NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
+                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
+                              DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
+                              bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
+                              eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
+                              7z5OXogYVaFzHKillDt3HRxHIZM= )
+   a.example.     3600 IN NS  ns1.a.example.
+                  3600 IN NS  ns2.a.example.
+                  3600 DS     57855 5 1 (
+                              B6DCD485719ADCA18E5F3D48A2331627FDD3
+                              636B )
+                  3600 RRSIG  DS 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+                  3600 NSEC   ai.example. NS DS RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
+                              U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
+                              039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
+                              BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
+                              sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+   ai.example.    3600 IN A   192.0.2.9
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 40]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+                  3600 HINFO  "KLH-10" "ITS"
+                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
+                              e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
+                              ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
+                              AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
+                              FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
+                  3600 AAAA   2001:db8::f00:baa9
+                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
+                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
+                              CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
+                              P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
+                              3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
+                              AhS+JOVfDI/79QtyTI0SaDWcg8U= )
+   b.example.     3600 IN NS  ns1.b.example.
+                  3600 IN NS  ns2.b.example.
+                  3600 NSEC   ns1.example. NS RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+   ns1.example.   3600 IN A   192.0.2.1
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 41]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
+                  3600 NSEC   ns2.example. A RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+   ns2.example.   3600 IN A   192.0.2.2
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+                  3600 NSEC   *.w.example. A RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
+                              VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
+                              3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
+                              l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
+                              Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
+   *.w.example.   3600 IN MX  1 ai.example.
+                  3600 RRSIG  MX 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+                              4kX18MMR34i8lC36SR5xBni8vHI= )
+                  3600 NSEC   x.w.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
+   x.w.example.   3600 IN MX  1 xx.example.
+                  3600 RRSIG  MX 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 42]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+                  3600 NSEC   x.y.w.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
+                              vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
+                              mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
+                              NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
+                              IjgiM8PXkBQtxPq37wDKALkyn7Q= )
+   x.y.w.example. 3600 IN MX  1 xx.example.
+                  3600 RRSIG  MX 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
+                              t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
+                              q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
+                              GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
+                              +gLcMZBnHJ326nb/TOOmrqNmQQE= )
+                  3600 NSEC   xx.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+   xx.example.    3600 IN A   192.0.2.10
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+                  3600 HINFO  "KLH-10" "TOPS-20"
+                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
+                              t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
+                              BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
+                              3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
+                              RgNvuwbioFSEuv2pNlkq0goYxNY= )
+                  3600 AAAA   2001:db8::f00:baaa
+                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 43]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
+                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
+                              9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
+                              mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
+                              asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
+                              GghLahumFIpg4MO3LS/prgzVVWo= )
+
+   The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
+   Flags indicate that each of these DNSKEY RRs is a zone key.  One of
+   these DNSKEY RRs also has the SEP flag set and has been used to sign
+   the apex DNSKEY RRset; this is the key which should be hashed to
+   generate a DS record to be inserted into the parent zone.  The other
+   DNSKEY is used to sign all the other RRsets in the zone.
+
+   The zone includes a wildcard entry "*.w.example".  Note that the name
+   "*.w.example" is used in constructing NSEC chains, and that the RRSIG
+   covering the "*.w.example" MX RRset has a label count of 2.
+
+   The zone also includes two delegations.  The delegation to
+   "b.example" includes an NS RRset, glue address records, and an NSEC
+   RR; note that only the NSEC RRset is signed.  The delegation to
+   "a.example" provides a DS RR; note that only the NSEC and DS RRsets
+   are signed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 44]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+Appendix B.  Example Responses
+
+   The examples in this section show response messages using the signed
+   zone example in Appendix A.
+
+B.1  Answer
+
+   A successful query to an authoritative server.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   x.w.example.        IN MX
+
+   ;; Answer
+   x.w.example.   3600 IN MX  1 xx.example.
+   x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+
+   ;; Authority
+   example.       3600 NS     ns1.example.
+   example.       3600 NS     ns2.example.
+   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+
+   ;; Additional
+   xx.example.    3600 IN A   192.0.2.10
+   xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+   xx.example.    3600 AAAA   2001:db8::f00:baaa
+   xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 45]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
+   ns1.example.   3600 IN A   192.0.2.1
+   ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
+   ns2.example.   3600 IN A   192.0.2.2
+   ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+
+
+B.2  Name Error
+
+   An authoritative name error.  The NSEC RRs prove that the name does
+   not exist and that no covering wildcard exists.
+
+   ;; Header: QR AA DO RCODE=3
+   ;;
+   ;; Question
+   ml.example.         IN A
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 46]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
+   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+   ;; Additional
+   ;; (empty)
+
+
+B.3  No Data Error
+
+   A "no data" response.  The NSEC RR proves that the name exists and
+   that the requested RR type does not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 47]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   ns1.example.        IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
+   ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+
+   ;; Additional
+   ;; (empty)
+
+
+B.4  Referral to Signed Zone
+
+   Referral to a signed zone.  The DS RR contains the data which the
+   resolver will need to validate the corresponding DNSKEY RR in the
+   child zone's apex.
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 48]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   ;; Header: QR DO RCODE=0
+   ;;
+   ;; Question
+   mc.a.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   a.example.     3600 IN NS  ns1.a.example.
+   a.example.     3600 IN NS  ns2.a.example.
+   a.example.     3600 DS     57855 5 1 (
+                              B6DCD485719ADCA18E5F3D48A2331627FDD3
+                              636B )
+   a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+
+   ;; Additional
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+
+
+B.5  Referral to Unsigned Zone
+
+   Referral to an unsigned zone.  The NSEC RR proves that no DS RR for
+   this delegation exists in the parent zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 49]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   ;; Header: QR DO RCODE=0
+   ;;
+   ;; Question
+   mc.b.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   b.example.     3600 IN NS  ns1.b.example.
+   b.example.     3600 IN NS  ns2.b.example.
+   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
+   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+
+   ;; Additional
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+
+
+B.6  Wildcard Expansion
+
+   A successful query which was answered via wildcard expansion.  The
+   label count in the answer's RRSIG RR indicates that a wildcard RRset
+   was expanded to produce this response, and the NSEC RR proves that no
+   closer match exists in the zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN MX
+
+   ;; Answer
+   a.z.w.example. 3600 IN MX  1 ai.example.
+   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+                              4kX18MMR34i8lC36SR5xBni8vHI= )
+
+   ;; Authority
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 50]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   example.       3600 NS     ns1.example.
+   example.       3600 NS     ns2.example.
+   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
+   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+
+   ;; Additional
+   ai.example.    3600 IN A   192.0.2.9
+   ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+   ai.example.    3600 AAAA   2001:db8::f00:baa9
+   ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
+
+
+B.7  Wildcard No Data Error
+
+   A "no data" response for a name covered by a wildcard.  The NSEC RRs
+   prove that the matching wildcard name does not have any RRs of the
+   requested type and that no closer match exists in the zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN AAAA
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 51]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
+   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
+   *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
+
+   ;; Additional
+   ;; (empty)
+
+
+B.8  DS Child Zone No Data Error
+
+   A "no data" response for a QTYPE=DS query which was mistakenly sent
+   to a name server for the child zone.
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 52]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   example.            IN DS
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+   ;; Additional
+   ;; (empty)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 53]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+Appendix C.  Authentication Examples
+
+   The examples in this section show how the response messages in
+   Appendix B are authenticated.
+
+C.1  Authenticating An Answer
+
+   The query in section Appendix B.1 returned an MX RRset for
+   "x.w.example.com".  The corresponding RRSIG indicates the MX RRset
+   was signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
+   The resolver needs the corresponding DNSKEY RR in order to
+   authenticate this answer.  The discussion below describes how a
+   resolver might obtain this DNSKEY RR.
+
+   The RRSIG indicates the original TTL of the MX RRset was 3600 and,
+   for the purpose of authentication, the current TTL is replaced by
+   3600.  The RRSIG labels field value of 3 indicates the answer was not
+   the result of wildcard expansion.  The "x.w.example.com" MX RRset is
+   placed in canonical form and, assuming the current time falls between
+   the signature inception and expiration dates, the signature is
+   authenticated.
+
+C.1.1  Authenticating the example DNSKEY RR
+
+   This example shows the logical authentication process that starts
+   from the a configured root DNSKEY (or DS RR) and moves down the tree
+   to authenticate the desired "example" DNSKEY RR.  Note the logical
+   order is presented for clarity and an implementation may choose to
+   construct the authentication as referrals are received or may choose
+   to construct the authentication chain only after all RRsets have been
+   obtained, or in any other combination it sees fit.  The example here
+   demonstrates only the logical process and does not dictate any
+   implementation rules.
+
+   We assume the resolver starts with an configured DNSKEY RR for the
+   root zone (or a configured DS RR for the root zone).  The resolver
+   checks this configured DNSKEY RR is present in the root DNSKEY RRset
+   (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this
+   DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime
+   is valid.  If all these conditions are met, all keys in the DNSKEY
+   RRset are considered authenticated.  The resolver then uses one (or
+   more) of the root DNSKEY RRs to authenticate the "example" DS RRset.
+   Note the resolver may need to query the root zone to obtain the root
+   DNSKEY RRset or "example" DS RRset.
+
+   Once the DS RRset has been authenticated using the root DNSKEY, the
+   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
+   RR that matches one of the authenticated "example" DS RRs.  If such a
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 54]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   matching "example" DNSKEY is found, the resolver checks this DNSKEY
+   RR has signed the "example" DNSKEY RRset and the signature lifetime
+   is valid.  If all these conditions are met, all keys in the "example"
+   DNSKEY RRset are considered authenticated.
+
+   Finally the resolver checks that some DNSKEY RR in the "example"
+   DNSKEY RRset uses algorithm 5 and has a key tag of 38519.  This
+   DNSKEY is used to authenticated the RRSIG included in the response.
+   If multiple "example" DNSKEY RRs match this algorithm and key tag,
+   then each DNSKEY RR is tried and the answer is authenticated if any
+   of the matching DNSKEY RRs validates the signature as described
+   above.
+
+C.2  Name Error
+
+   The query in section Appendix B.2 returned NSEC RRs that prove the
+   requested data does not exist and no wildcard applies.  The negative
+   reply is authenticated by verifying both NSEC RRs.  The NSEC RRs are
+   authenticated in a manner identical to that of the MX RRset discussed
+   above.
+
+C.3  No Data Error
+
+   The query in section Appendix B.3 returned an NSEC RR that proves the
+   requested name exists, but the requested RR type does not exist.  The
+   negative reply is authenticated by verifying the NSEC RR.  The NSEC
+   RR is authenticated in a manner identical to that of the MX RRset
+   discussed above.
+
+C.4  Referral to Signed Zone
+
+   The query in section Appendix B.4 returned a referral to the signed
+   "a.example." zone.  The DS RR is authenticated in a manner identical
+   to that of the MX RRset discussed above.  This DS RR is used to
+   authenticate the "a.example" DNSKEY RRset.
+
+   Once the "a.example" DS RRset has been authenticated using the
+   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
+   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
+   matching "a.example" DNSKEY is found, the resolver checks this DNSKEY
+   RR has signed the "a.example" DNSKEY RRset and the signature lifetime
+   is valid.  If all these conditions are met, all keys in the
+   "a.example" DNSKEY RRset are considered authenticated.
+
+C.5  Referral to Unsigned Zone
+
+   The query in section Appendix B.5 returned a referral to an unsigned
+   "b.example." zone.  The NSEC proves that no authentication leads from
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 55]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+   "example" to "b.example" and the NSEC RR is authenticated in a manner
+   identical to that of the MX RRset discussed above.
+
+C.6  Wildcard Expansion
+
+   The query in section Appendix B.6 returned an answer that was
+   produced as a result of wildcard expansion.  The RRset expanded as
+   the similar to The corresponding RRSIG indicates the MX RRset was
+   signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
+   The RRSIG indicates the original TTL of the MX RRset was 3600 and,
+   for the purpose of authentication, the current TTL is replaced by
+   3600.  The RRSIG labels field value of 2 indicates the answer the
+   result of wildcard expansion since the "a.z.w.example" name contains
+   4 labels.  The name "a.z.w.w.example" is replaced by "*.w.example",
+   the MX RRset is placed in canonical form and, assuming the current
+   time falls between the signature inception and expiration dates, the
+   signature is authenticated.
+
+   The NSEC proves that no closer match (exact or closer wildcard) could
+   have been used to answer this query and the NSEC RR must also be
+   authenticated before the answer is considered valid.
+
+C.7  Wildcard No Data Error
+
+   The query in section Appendix B.7 returned NSEC RRs that prove the
+   requested data does not exist and no wildcard applies.  The negative
+   reply is authenticated by verifying both NSEC RRs.
+
+C.8  DS Child Zone No Data Error
+
+   The query in section Appendix B.8 returned NSEC RRs that shows the
+   requested was answered by a child server ("example" server).  The
+   NSEC RR indicates the presence of an SOA RR, showing the answer is
+   from the child .  Queries for the "example" DS RRset should be sent
+   to the parent servers ("root" servers).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 56]
+
+Internet-Draft       DNSSEC Protocol Modifications             July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 57]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
index 3ca99bfb..79a17284 100644
--- a/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt
+++ b/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
@@ -1,1961 +1,1849 @@
-

-

-DNS Extensions                                                 R. Arends

-Internet-Draft                                      Telematica Instituut

-Expires: November 15, 2004                                    R. Austein

-                                                                     ISC

-                                                               M. Larson

-                                                                VeriSign

-                                                               D. Massey

-                                                                 USC/ISI

-                                                                 S. Rose

-                                                                    NIST

-                                                            May 17, 2004

-

-

-            Resource Records for the DNS Security Extensions

-                  draft-ietf-dnsext-dnssec-records-08

-

-Status of this Memo

-

-   This document is an Internet-Draft and is in full conformance with

-   all provisions of Section 10 of RFC2026.

-

-   Internet-Drafts are working documents of the Internet Engineering

-   Task Force (IETF), its areas, and its working groups. Note that other

-   groups may also distribute working documents as Internet-Drafts.

-

-   Internet-Drafts are draft documents valid for a maximum of six months

-   and may be updated, replaced, or obsoleted by other documents at any

-   time. It is inappropriate to use Internet-Drafts as reference

-   material or to cite them other than as "work in progress."

-

-   The list of current Internet-Drafts can be accessed at http://

-   www.ietf.org/ietf/1id-abstracts.txt.

-

-   The list of Internet-Draft Shadow Directories can be accessed at

-   http://www.ietf.org/shadow.html.

-

-   This Internet-Draft will expire on November 15, 2004.

-

-Copyright Notice

-

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

-

-Abstract

-

-   This document is part of a family of documents that describes the DNS

-   Security Extensions (DNSSEC).  The DNS Security Extensions are a

-   collection of resource records and protocol modifications that

-   provide source authentication for the DNS. This document defines the

-   public key (DNSKEY), delegation signer (DS), resource record digital

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 1]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   signature (RRSIG), and authenticated denial of existence (NSEC)

-   resource records.  The purpose and format of each resource record is

-   described in detail, and an example of each resource record is given.

-

-   This document obsoletes RFC 2535 and incorporates changes from all

-   updates to RFC 2535.

-

-Table of Contents

-

-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

-     1.1   Background and Related Documents . . . . . . . . . . . . .  4

-     1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4

-     1.3   Editors' Notes . . . . . . . . . . . . . . . . . . . . . .  4

-       1.3.1   Technical Changes or Corrections . . . . . . . . . . .  4

-       1.3.2   Typos and Minor Corrections  . . . . . . . . . . . . .  5

-   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . . .  6

-     2.1   DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . .  6

-       2.1.1   The Flags Field  . . . . . . . . . . . . . . . . . . .  6

-       2.1.2   The Protocol Field . . . . . . . . . . . . . . . . . .  7

-       2.1.3   The Algorithm Field  . . . . . . . . . . . . . . . . .  7

-       2.1.4   The Public Key Field . . . . . . . . . . . . . . . . .  7

-       2.1.5   Notes on DNSKEY RDATA Design . . . . . . . . . . . . .  7

-     2.2   The DNSKEY RR Presentation Format  . . . . . . . . . . . .  7

-     2.3   DNSKEY RR Example  . . . . . . . . . . . . . . . . . . . .  8

-   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . . .  9

-     3.1   RRSIG RDATA Wire Format  . . . . . . . . . . . . . . . . .  9

-       3.1.1   The Type Covered Field . . . . . . . . . . . . . . . . 10

-       3.1.2   The Algorithm Number Field . . . . . . . . . . . . . . 10

-       3.1.3   The Labels Field . . . . . . . . . . . . . . . . . . . 10

-       3.1.4   Original TTL Field . . . . . . . . . . . . . . . . . . 11

-       3.1.5   Signature Expiration and Inception Fields  . . . . . . 11

-       3.1.6   The Key Tag Field  . . . . . . . . . . . . . . . . . . 11

-       3.1.7   The Signer's Name Field  . . . . . . . . . . . . . . . 12

-       3.1.8   The Signature Field  . . . . . . . . . . . . . . . . . 12

-     3.2   The RRSIG RR Presentation Format . . . . . . . . . . . . . 13

-     3.3   RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13

-   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 15

-     4.1   NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 15

-       4.1.1   The Next Domain Name Field . . . . . . . . . . . . . . 15

-       4.1.2   The Type Bit Maps Field  . . . . . . . . . . . . . . . 16

-       4.1.3   Inclusion of Wildcard Names in NSEC RDATA  . . . . . . 17

-     4.2   The NSEC RR Presentation Format  . . . . . . . . . . . . . 17

-     4.3   NSEC RR Example  . . . . . . . . . . . . . . . . . . . . . 17

-   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . . 19

-     5.1   DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 19

-       5.1.1   The Key Tag Field  . . . . . . . . . . . . . . . . . . 20

-       5.1.2   The Algorithm Field  . . . . . . . . . . . . . . . . . 20

-       5.1.3   The Digest Type Field  . . . . . . . . . . . . . . . . 20

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 2]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-       5.1.4   The Digest Field . . . . . . . . . . . . . . . . . . . 20

-     5.2   Processing of DS RRs When Validating Responses . . . . . . 20

-     5.3   The DS RR Presentation Format  . . . . . . . . . . . . . . 21

-     5.4   DS RR Example  . . . . . . . . . . . . . . . . . . . . . . 21

-   6.  Canonical Form and Order of Resource Records . . . . . . . . . 22

-     6.1   Canonical DNS Name Order . . . . . . . . . . . . . . . . . 22

-     6.2   Canonical RR Form  . . . . . . . . . . . . . . . . . . . . 22

-     6.3   Canonical RR Ordering Within An RRset  . . . . . . . . . . 23

-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24

-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25

-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26

-   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 27

-   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 27

-   10.2  Informative References . . . . . . . . . . . . . . . . . . . 28

-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28

-   A.  DNSSEC Algorithm and Digest Types  . . . . . . . . . . . . . . 30

-     A.1   DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 30

-       A.1.1   Private Algorithm Types  . . . . . . . . . . . . . . . 30

-     A.2   DNSSEC Digest Types  . . . . . . . . . . . . . . . . . . . 31

-   B.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . . . . 32

-     B.1   Key Tag for Algorithm 1 (RSA/MD5)  . . . . . . . . . . . . 33

-       Intellectual Property and Copyright Statements . . . . . . . . 34

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 3]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-1.  Introduction

-

-   The DNS Security Extensions (DNSSEC) introduce four new DNS resource

-   record types: DNSKEY, RRSIG, NSEC, and DS.  This document defines the

-   purpose of each resource record (RR), the RR's RDATA format, and its

-   presentation format (ASCII representation).

-

-1.1  Background and Related Documents

-

-   The reader is assumed to be familiar with the basic DNS concepts

-   described in [RFC1034], [RFC1035] and subsequent RFCs that update

-   them:  [RFC2136], [RFC2181] and [RFC2308].

-

-   This document is part of a family of documents that define the DNS

-   security extensions.  The DNS security extensions (DNSSEC) are a

-   collection of resource records and DNS protocol modifications that

-   add source authentication and data integrity to the Domain Name

-   System (DNS).  An introduction to DNSSEC and definitions of common

-   terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description

-   of DNS protocol modifications can be found in

-   [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC

-   resource records.

-

-1.2  Reserved Words

-

-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this

-   document are to be interpreted as described in RFC 2119 [RFC2119].

-

-1.3  Editors' Notes

-

-1.3.1  Technical Changes or Corrections

-

-   Please report technical corrections to dnssec-editors@east.isi.edu.

-   To assist the editors, please indicate the text in error and point

-   out the RFC that defines the correct behavior.  For a technical

-   change where no RFC that defines the correct behavior, or if there's

-   more than one applicable RFC and the definitions conflict, please

-   post the issue to namedroppers.

-

-   An example correction to dnssec-editors might be: Page X says

-   "DNSSEC RRs SHOULD be automatically returned in responses."  This was

-   true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the

-   DNSSEC RR types MUST NOT be included in responses unless the resolver

-   indicated support for DNSSEC.

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 4]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-1.3.2  Typos and Minor Corrections

-

-   Please report any typos corrections to dnssec-editors@east.isi.edu.

-   To assist the editors, please provide enough context for us to find

-   the incorrect text quickly.

-

-   An example message to dnssec-editors might be: page X says "the

-   DNSSEC standard has been in development for over 1 years".   It

-   should read "over 10 years".

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 5]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-2.  The DNSKEY Resource Record

-

-   DNSSEC uses public key cryptography to sign and authenticate DNS

-   resource record sets (RRsets).  The public keys are stored in DNSKEY

-   resource records and are used in the DNSSEC authentication process

-   described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its

-   authoritative RRsets using a private key and stores the corresponding

-   public key in a DNSKEY RR.  A resolver can then use the public key to

-   authenticate signatures covering the RRsets in the zone.

-

-   The DNSKEY RR is not intended as a record for storing arbitrary

-   public keys and MUST NOT be used to store certificates or public keys

-   that do not directly relate to the DNS infrastructure.

-

-   The Type value for the DNSKEY RR type is 48.

-

-   The DNSKEY RR is class independent.

-

-   The DNSKEY RR has no special TTL requirements.

-

-2.1  DNSKEY RDATA Wire Format

-

-   The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1

-   octet Protocol Field, a 1 octet Algorithm Field, and the Public Key

-   Field.

-

-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3

-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |              Flags            |    Protocol   |   Algorithm   |

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   /                                                               /

-   /                            Public Key                         /

-   /                                                               /

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-

-

-2.1.1  The Flags Field

-

-   Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,

-   then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner

-   name MUST be the name of a zone. If bit 7 has value 0, then the

-   DNSKEY record holds some other type of DNS public key, such as a

-   public key used by TKEY and MUST NOT be used to verify RRSIGs that

-   cover RRsets.

-

-   Bit 15 of the Flags field is the Secure Entry Point flag, described

-   in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 6]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   key intended for use as a secure entry point.  This flag is only

-   intended to be to a hint to zone signing or debugging software as to

-   the intended use of this DNSKEY record; validators MUST NOT alter

-   their behavior during the signature validation process in any way

-   based on the setting of this bit.  This also means a DNSKEY RR with

-   the SEP bit set would also need the Zone Key flag set in order to

-   legally be able to generate signatures.  A DNSKEY RR with the SEP set

-   and the Zone Key flag not set is an invalid DNSKEY.

-

-   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon

-   creation of the DNSKEY RR, and MUST be ignored upon reception.

-

-2.1.2  The Protocol Field

-

-   The Protocol Field MUST have value 3 and the DNSKEY RR MUST be

-   treated as invalid during signature verification if found to be some

-   value other than 3.

-

-2.1.3  The Algorithm Field

-

-   The Algorithm field identifies the public key's cryptographic

-   algorithm and determines the format of the Public Key field.  A list

-   of DNSSEC algorithm types can be found in Appendix A.1

-

-2.1.4  The Public Key Field

-

-   The Public Key Field holds the public key material.  The format

-   depends on the algorithm of the key being stored and are described in

-   separate documents.

-

-2.1.5  Notes on DNSKEY RDATA Design

-

-   Although the Protocol Field always has value 3, it is retained for

-   backward compatibility with early versions of the KEY record.

-

-2.2  The DNSKEY RR Presentation Format

-

-   The presentation format of the RDATA portion is as follows:

-

-   The Flag field MUST be represented as an unsigned decimal integer

-   with a value of 0, 256, or 257.

-

-   The Protocol Field MUST be represented as an unsigned decimal integer

-   with a value of 3.

-

-   The Algorithm field MUST be represented either as an unsigned decimal

-   integer or as an algorithm mnemonic as specified in Appendix A.1.

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 7]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   The Public Key field MUST be represented as a Base64 encoding of the

-   Public Key.  Whitespace is allowed within the Base64 text.  For a

-   definition of Base64 encoding, see [RFC1521] Section 5.2.

-

-2.3  DNSKEY RR Example

-

-   The following DNSKEY RR stores a DNS zone key for example.com.

-

-   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3

-                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no

-                                          kfzj31GajIQKY+5CptLr3buXA10h

-                                          WqTkF7H6RfoRqXQeogmMHfpftf6z

-                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL

-                                          742iU/TpPSEDhm2SNKLijfUppn1U

-                                          aNvv4w==  )

-

-   The first four text fields specify the owner name, TTL, Class, and RR

-   type (DNSKEY).  Value 256 indicates that the Zone Key bit (bit 7) in

-   the Flags field has value 1.  Value 3 is the fixed Protocol value.

-   Value 5 indicates the public key algorithm.  Appendix A.1 identifies

-   algorithm type 5 as RSA/SHA1 and indicates that the format of the

-   RSA/SHA1 public key field is defined in [RFC3110].  The remaining

-   text is a Base64 encoding of the public key.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 8]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-3.  The RRSIG Resource Record

-

-   DNSSEC uses public key cryptography to sign and authenticate DNS

-   resource record sets (RRsets).  Digital signatures are stored in

-   RRSIG resource records and are used in the DNSSEC authentication

-   process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator

-   can use these RRSIG RRs to authenticate RRsets from the zone.  The

-   RRSIG RR MUST only be used to carry verification material (digital

-   signatures) used to secure DNS operations.

-

-   An RRSIG record contains the signature for an RRset with a particular

-   name, class, and type.  The RRSIG RR specifies a validity interval

-   for the signature and uses the Algorithm, the Signer's Name, and the

-   Key Tag to identify the DNSKEY RR containing the public key that a

-   validator can use to verify the signature.

-

-   Because every authoritative RRset in a zone must be protected by a

-   digital signature, RRSIG RRs must be present for names containing a

-   CNAME RR.  This is a change to the traditional DNS specification

-   [RFC1034] that stated that if a CNAME is present for a name, it is

-   the only type allowed at that name.  A RRSIG and NSEC (see Section 4)

-   MUST exist for the same name as a CNAME resource record in a signed

-   zone.

-

-   The Type value for the RRSIG RR type is 46.

-

-   The RRSIG RR is class independent.

-

-   An RRSIG RR MUST have the same class as the RRset it covers.

-

-   The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset

-   it covers.  This is an exception to the [RFC2181] rules for TTL

-   values of individual RRs within a RRset: individual RRSIG with the

-   same owner name will have different TTL values if the RRsets they

-   cover have different TTL values.

-

-3.1  RRSIG RDATA Wire Format

-

-   The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a

-   1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original

-   TTL field, a 4 octet Signature Expiration field, a 4 octet Signature

-   Inception field, a 2 octet Key tag, the Signer's Name field, and the

-   Signature field.

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004                [Page 9]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3

-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |        Type Covered           |  Algorithm    |     Labels    |

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |                         Original TTL                          |

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |                      Signature Expiration                     |

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |                      Signature Inception                      |

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |            Key Tag            |                               /

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /

-   /                                                               /

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   /                                                               /

-   /                            Signature                          /

-   /                                                               /

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-

-

-3.1.1  The Type Covered Field

-

-   The Type Covered field identifies the type of the RRset that is

-   covered by this RRSIG record.

-

-3.1.2  The Algorithm Number Field

-

-   The Algorithm Number field identifies the cryptographic algorithm

-   used to create the signature.  A list of DNSSEC algorithm types can

-   be found in Appendix A.1

-

-3.1.3  The Labels Field

-

-   The Labels field specifies the number of labels in the original RRSIG

-   RR owner name. The significance of this field is that a validator

-   uses it to determine if the answer was synthesized from a wildcard.

-   If so, it can be used to determine what owner name was used in

-   generating the signature.

-

-   To validate a signature, the validator needs the original owner name

-   that was used to create the signature. If the original owner name

-   contains a wildcard label ("*"), the owner name may have been

-   expanded by the server during the response process, in which case the

-   validator will need to reconstruct the original owner name in order

-   to validate the signature.  [I-D.ietf-dnsext-dnssec-protocol]

-   describes how to use the Labels field to reconstruct the original

-   owner name.

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 10]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   The value of the Labels field MUST NOT count either the null (root)

-   label that terminates the owner name or the wildcard label (if

-   present).  The value of the Labels field MUST be less than or equal

-   to the number of labels in the RRSIG owner name.  For example,

-   "www.example.com." has a Labels field value of 3, and

-   "*.example.com." has a Labels field value of 2.  Root (".") has a

-   Labels field value of 0.

-

-   Although the wildcard label is not included in the count stored in

-   the Labels field of the RRSIG RR, the wildcard label is part of the

-   RRset's owner name when generating or verifying the signature.

-

-3.1.4  Original TTL Field

-

-   The Original TTL field specifies the TTL of the covered RRset as it

-   appears in the authoritative zone.

-

-   The Original TTL field is necessary because a caching resolver

-   decrements the TTL value of a cached RRset. In order to validate a

-   signature, a validator requires the original TTL.

-   [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original

-   TTL field value to reconstruct the original TTL.

-

-3.1.5  Signature Expiration and Inception Fields

-

-   The Signature Expiration and Inception fields specify a validity

-   period for the signature.  The RRSIG record MUST NOT be used for

-   authentication prior to the inception date and MUST NOT be used for

-   authentication after the expiration date.

-

-   Signature Expiration and Inception field values are in POSIX.1 time

-   format: a 32-bit unsigned number of seconds elapsed since 1 January

-   1970 00:00:00 UTC, ignoring leap seconds, in network byte order.  The

-   longest interval which can be expressed by this format without

-   wrapping is approximately 136 years.  An RRSIG RR can have an

-   Expiration field value which is numerically smaller than the

-   Inception field value if the expiration field value is near the

-   32-bit wrap-around point or if the signature is long lived.  Because

-   of this, all comparisons involving these fields MUST use "Serial

-   number arithmetic" as defined in [RFC1982].  As a direct consequence,

-   the values contained in these fields cannot refer to dates more than

-   68 years in either the past or the future.

-

-3.1.6  The Key Tag Field

-

-   The Key Tag field contains the key tag value of the DNSKEY RR that

-   validates this signature.  Appendix B explains how to calculate Key

-   Tag values.

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 11]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-3.1.7  The Signer's Name Field

-

-   The Signer's Name field value identifies the owner name of the DNSKEY

-   RR which a validator should use to validate this signature.  The

-   Signer's Name field MUST contain the name of the zone of the covered

-   RRset.  A sender MUST NOT use DNS name compression on the Signer's

-   Name field when transmitting a RRSIG RR.

-

-3.1.8  The Signature Field

-

-   The Signature field contains the cryptographic signature that covers

-   the RRSIG RDATA (excluding the Signature field) and the RRset

-   specified by the RRSIG owner name, RRSIG class, and RRSIG Type

-   Covered field.  The format of this field depends on the algorithm in

-   use and these formats are described in separate companion documents.

-

-3.1.8.1  Signature Calculation

-

-   A signature covers the RRSIG RDATA (excluding the Signature Field)

-   and covers the data RRset specified by the RRSIG owner name, RRSIG

-   class, and RRSIG Type Covered fields.  The RRset is in canonical form

-   (see Section 6) and the set RR(1),...RR(n) is signed as follows:

-

-         signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where

-

-            "|" denotes concatenation;

-

-            RRSIG_RDATA is the wire format of the RRSIG RDATA fields

-               with the Signer's Name field in canonical form and

-               the Signature field excluded;

-

-            RR(i) = owner | type | class | TTL | RDATA length | RDATA

-

-               "owner" is the fully qualified owner name of the RRset in

-               canonical form (for RRs with wildcard owner names, the

-               wildcard label is included in the owner name);

-

-               Each RR MUST have the same owner name as the RRSIG RR;

-

-               Each RR MUST have the same class as the RRSIG RR;

-

-               Each RR in the RRset MUST have the RR type listed in the

-               RRSIG RR's Type Covered field;

-

-               Each RR in the RRset MUST have the TTL listed in the

-               RRSIG Original TTL Field;

-

-               Any DNS names in the RDATA field of each RR MUST be in

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 12]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-               canonical form; and

-

-               The RRset MUST be sorted in canonical order.

-

-   See Section 6.1 and Section 6.2 for details on canonical name order

-   and canonical RR form.

-

-3.2  The RRSIG RR Presentation Format

-

-   The presentation format of the RDATA portion is as follows:

-

-   The Type Covered field is represented as a RR type mnemonic.  When

-   the mnemonic is not known, the TYPE representation as described in

-   [RFC3597] (section 5) MUST be used.

-

-   The Algorithm field value MUST be represented either as an unsigned

-   decimal  integer or as an algorithm mnemonic as specified in Appendix

-   A.1.

-

-   The Labels field value MUST be represented as an unsigned decimal

-   integer.

-

-   The Original TTL field value MUST be represented as an unsigned

-   decimal integer.

-

-   The Signature Expiration Time and Inception Time field values MUST be

-   represented either as seconds since 1 January 1970 00:00:00 UTC or in

-   the form YYYYMMDDHHmmSS in UTC, where:

-      YYYY is the year (0000-9999, but see Section 3.1.5);

-      MM is the month number (01-12);

-      DD is the day of the month (01-31);

-      HH is the hour in 24 hours notation (00-23);

-      mm is the minute (00-59); and

-      SS is the second (00-59).

-

-   The Key Tag field MUST be represented as an unsigned decimal integer.

-

-   The Signer's Name field value MUST be represented as a domain name.

-

-   The Signature field is represented as a Base64 encoding of the

-   signature.  Whitespace is allowed within the Base64 text.  See

-   Section 2.2.

-

-3.3  RRSIG RR Example

-

-   The following RRSIG RR stores the signature for the A RRset of

-   host.example.com:

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 13]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (

-                                  20030220173103 2642 example.com.

-                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr

-                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o

-                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t

-                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG

-                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

-

-   The first four fields specify the owner name, TTL, Class, and RR type

-   (RRSIG).  The "A" represents the Type Covered field. The value 5

-   identifies the algorithm used (RSA/SHA1) to create the signature.

-   The value 3 is the number of Labels in the original owner name.  The

-   value 86400 in the RRSIG RDATA is the Original TTL for the covered A

-   RRset.  20030322173103 and 20030220173103 are the expiration and

-   inception dates, respectively.  2642 is the Key Tag, and example.com.

-   is the Signer's Name.  The remaining text is a Base64 encoding of the

-   signature.

-

-   Note that combination of RRSIG RR owner name, class, and Type Covered

-   indicate that this RRSIG covers the "host.example.com" A RRset.  The

-   Label value of 3 indicates that no wildcard expansion was used.  The

-   Algorithm, Signer's Name, and Key Tag indicate this signature can be

-   authenticated using an example.com zone DNSKEY RR whose algorithm is

-   5 and key tag is 2642.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 14]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-4.  The NSEC Resource Record

-

-   The NSEC resource record lists two separate things: the owner name of

-   the next authoritative RRset in the canonical ordering of the zone,

-   and the set of RR types present at the NSEC RR's owner name.  The

-   complete set of NSEC RRs in a zone both indicate which authoritative

-   RRsets exist in a zone and also form a chain of authoritative owner

-   names in the zone.  This information is used to provide authenticated

-   denial of existence for DNS data, as described in

-   [I-D.ietf-dnsext-dnssec-protocol].

-

-   Because every authoritative name in a zone must be part of the NSEC

-   chain, NSEC RRs must be present for names containing a CNAME RR.

-   This is a change to the traditional DNS specification [RFC1034] that

-   stated that if a CNAME is present for a name, it is the only type

-   allowed at that name.  An RRSIG (see Section 3) and NSEC MUST exist

-   for the same name as a CNAME resource record in a signed zone.

-

-   See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone

-   signer determines precisely which NSEC RRs it needs to include in a

-   zone.

-

-   The type value for the NSEC RR is 47.

-

-   The NSEC RR is class independent.

-

-   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL

-   field. This is in the spirit of negative caching [RFC2308].

-

-4.1  NSEC RDATA Wire Format

-

-   The RDATA of the NSEC RR is as shown below:

-

-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3

-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   /                      Next Domain Name                         /

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   /                       Type Bit Maps                           /

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-

-

-4.1.1  The Next Domain Name Field

-

-   The Next Domain Name field contains the owner name of the next

-   authoritative owner name in the canonical ordering of the zone; see

-   Section 6.1 for an explanation of canonical ordering.  The value of

-   the Next Domain Name field in the last NSEC record in the zone is the

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 15]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   name of the zone apex (the owner name of the zone's SOA RR).

-

-   A sender MUST NOT use DNS name compression on the Next Domain Name

-   field when transmitting an NSEC RR.

-

-   Owner names of RRsets not authoritative for the given zone (such as

-   glue records) MUST NOT be listed in the Next Domain Name unless at

-   least one authoritative RRset exists at the same owner name.

-

-4.1.2  The Type Bit Maps Field

-

-   The Type Bit Maps field identifies the RRset types which exist at the

-   NSEC RR's owner name.

-

-   The RR type space is split into 256 window blocks, each representing

-   the low-order 8 bits of the 16-bit RR type space. Each block that has

-   at least one active RR type is encoded using a single octet window

-   number (from 0 to 255), a single octet bitmap length (from 1 to 32)

-   indicating the number of octets used for the window block's bitmap,

-   and up to 32 octets (256 bits) of bitmap.

-

-   Blocks are present in the NSEC RR RDATA in increasing numerical

-   order.

-

-      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+

-

-      where "|" denotes concatenation.

-

-   Each bitmap encodes the low-order 8 bits of RR types within the

-   window block, in network bit order.  The first bit is bit 0.  For

-   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds

-   to RR type 2 (NS), and so forth.  For window block 1, bit 1

-   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to

-   1, it indicates that an RRset of that type is present for the NSEC

-   RR's owner name.  If a bit is set to 0, it indicates that no RRset of

-   that type is present for the NSEC RR's owner name.

-

-   Bits representing pseudo-types MUST be set to 0, since they do not

-   appear in zone data.  If encountered, they MUST be ignored upon

-   reading.

-

-   Blocks with no types present MUST NOT be included. Trailing zero

-   octets in the bitmap MUST be omitted.  The length of each block's

-   bitmap is determined by the type code with the largest numerical

-   value, within that block, among the set of RR types present at the

-   NSEC RR's owner name.  Trailing zero octets not specified MUST be

-   interpreted as zero octets.

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 16]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   The bitmap for the NSEC RR at a delegation point requires special

-   attention.  Bits corresponding to the delegation NS RRset and the RR

-   types for which the parent zone has authoritative data MUST be set to

-   1; bits corresponding to any non-NS RRset for which the parent is not

-   authoritative MUST be set to 0.

-

-   A zone MUST NOT include an NSEC RR for any domain name that only

-   holds glue records.

-

-4.1.3  Inclusion of Wildcard Names in NSEC RDATA

-

-   If a wildcard owner name appears in a zone, the wildcard label ("*")

-   is treated as a literal symbol and is treated the same as any other

-   owner name for purposes of generating NSEC RRs.  Wildcard owner names

-   appear in the Next Domain Name field without any wildcard expansion.

-   [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards

-   on authenticated denial of existence.

-

-4.2  The NSEC RR Presentation Format

-

-   The presentation format of the RDATA portion is as follows:

-

-   The Next Domain Name field is represented as a domain name.

-

-   The Type Bit Maps field is represented as a sequence of RR type

-   mnemonics.  When the mnemonic is not known, the TYPE representation

-   as described in [RFC3597] (section 5) MUST be used.

-

-4.3  NSEC RR Example

-

-   The following NSEC RR identifies the RRsets associated with

-   alfa.example.com. and identifies the next authoritative name after

-   alfa.example.com.

-

-   alfa.example.com. 86400 IN NSEC host.example.com. (

-                                   A MX RRSIG NSEC TYPE1234 )

-

-   The first four text fields specify the name, TTL, Class, and RR type

-   (NSEC).  The entry host.example.com. is the next authoritative name

-   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,

-   and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and

-   TYPE1234 RRsets associated with the name alfa.example.com.

-

-   The RDATA section of the NSEC RR above would be encoded as:

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 17]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-            0x04 'h'  'o'  's'  't'

-            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'

-            0x03 'c'  'o'  'm'  0x00

-            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03

-            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00

-            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

-            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

-            0x00 0x00 0x00 0x00 0x20

-

-   Assuming that the validator can authenticate this NSEC record, it

-   could be used to prove that beta.example.com does not exist, or could

-   be used to prove there is no AAAA record associated with

-   alfa.example.com.  Authenticated denial of existence is discussed in

-   [I-D.ietf-dnsext-dnssec-protocol].

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 18]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-5.  The DS Resource Record

-

-   The DS Resource Record refers to a DNSKEY RR and is used in the DNS

-   DNSKEY authentication process. A DS RR refers to a DNSKEY RR by

-   storing the key tag, algorithm number, and a digest of the DNSKEY RR.

-   Note that while the digest should be sufficient to identify the

-   public key, storing the key tag and key algorithm helps make the

-   identification process more efficient.  By authenticating the DS

-   record, a resolver can authenticate the DNSKEY RR to which the DS

-   record points.  The key authentication process is described in

-   [I-D.ietf-dnsext-dnssec-protocol].

-

-   The DS RR and its corresponding DNSKEY RR have the same owner name,

-   but they are stored in different locations.  The DS RR appears only

-   on the upper (parental) side of a delegation, and is authoritative

-   data in the parent zone.  For example, the DS RR for "example.com" is

-   stored in the "com" zone (the parent zone) rather than in the

-   "example.com" zone (the child zone).  The corresponding DNSKEY RR is

-   stored in the "example.com" zone (the child zone).  This simplifies

-   DNS zone management and zone signing, but introduces special response

-   processing requirements for the DS RR; these are described in

-   [I-D.ietf-dnsext-dnssec-protocol].

-

-   The type number for the DS record is 43.

-

-   The DS resource record is class independent.

-

-   The DS RR has no special TTL requirements.

-

-5.1  DS RDATA Wire Format

-

-   The RDATA for a DS RR consists of a 2 octet Key Tag field, a one

-   octet Algorithm field, a one octet Digest Type field, and a Digest

-   field.

-

-                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3

-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   |           Key Tag             |  Algorithm    |  Digest Type  |

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-   /                                                               /

-   /                            Digest                             /

-   /                                                               /

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 19]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-5.1.1  The Key Tag Field

-

-   The Key Tag field lists the key tag of the DNSKEY RR referred to by

-   the DS record.

-

-   The Key Tag used by the DS RR is identical to the Key Tag used by

-   RRSIG RRs.  Appendix B describes how to compute a Key Tag.

-

-5.1.2  The Algorithm Field

-

-   The Algorithm field lists the algorithm number of the DNSKEY RR

-   referred to by the DS record.

-

-   The algorithm number used by the DS RR is identical to the algorithm

-   number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm

-   number types.

-

-5.1.3  The Digest Type Field

-

-   The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY

-   RR. The Digest Type field identifies the algorithm used to construct

-   the digest.  Appendix A.2 lists the possible digest algorithm types.

-

-5.1.4  The Digest Field

-

-   The DS record refers to a DNSKEY RR by including a digest of that

-   DNSKEY RR.

-

-   The digest is calculated by concatenating the canonical form of the

-   fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,

-   and then applying the digest algorithm.

-

-     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);

-

-      "|" denotes concatenation

-

-     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.

-

-

-   The size of the digest may vary depending on the digest algorithm and

-   DNSKEY RR size.  As of the time of writing, the only defined digest

-   algorithm is SHA-1, which produces a 20 octet digest.

-

-5.2  Processing of DS RRs When Validating Responses

-

-   The DS RR links the authentication chain across zone boundaries, so

-   the DS RR requires extra care in processing.  The DNSKEY RR referred

-   to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 20]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   have Flags bit 7 set to value 1. If the DNSKEY flags do not indicate

-   a DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT

-   be used in the validation process.

-

-5.3  The DS RR Presentation Format

-

-   The presentation format of the RDATA portion is as follows:

-

-   The Key Tag field MUST be represented as an unsigned decimal integer.

-

-   The Algorithm field MUST be represented either as an unsigned decimal

-   integer or as an algorithm mnemonic specified in Appendix A.1.

-

-   The Digest Type field MUST be represented as an unsigned decimal

-   integer.

-

-   The Digest MUST be represented as a sequence of case-insensitive

-   hexadecimal digits.  Whitespace is allowed within the hexadecimal

-   text.

-

-5.4  DS RR Example

-

-   The following example shows a DNSKEY RR and its corresponding DS RR.

-

-   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz

-                                             fwJr1AYtsmx3TGkJaNXVbfi/

-                                             2pHm822aJ5iI9BMzNXxeYCmZ

-                                             DRD99WYwYqUSdjMmmAphXdvx

-                                             egXd/M5+X7OrzKBaMbCVdFLU

-                                             Uh6DhweJBjEVv5f2wwjM9Xzc

-                                             nOf+EPbtG9DMBmADjFDc2w/r

-                                             ljwvFw==

-                                             ) ;  key id = 60485

-

-   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A

-                                              98631FAD1A292118 )

-

-

-   The first four text fields specify the name, TTL, Class, and RR type

-   (DS). Value 60485 is the key tag for the corresponding

-   "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm

-   used by this "dskey.example.com." DNSKEY RR.  The value 1 is the

-   algorithm used to construct the digest, and the rest of the RDATA

-   text is the digest in hexadecimal.

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 21]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-6.  Canonical Form and Order of Resource Records

-

-   This section defines a canonical form for resource records, a

-   canonical ordering of DNS names, and a canonical ordering of resource

-   records within an RRset.  A canonical name order is required to

-   construct the NSEC name chain.  A canonical RR form and ordering

-   within an RRset are required to construct and verify RRSIG RRs.

-

-6.1  Canonical DNS Name Order

-

-   For purposes of DNS security, owner names are ordered by treating

-   individual labels as unsigned left-justified octet strings.  The

-   absence of a octet sorts before a zero value octet, and upper case

-   US-ASCII letters are treated as if they were lower case US-ASCII

-   letters.

-

-   To compute the canonical ordering of a set of DNS names, start by

-   sorting the names according to their most significant (rightmost)

-   labels.  For names in which the most significant label is identical,

-   continue sorting according to their next most significant label, and

-   so forth.

-

-   For example, the following names are sorted in canonical DNS name

-   order.  The most significant label is "example".  At this level,

-   "example" sorts first, followed by names ending in "a.example", then

-   names ending "z.example".  The names within each level are sorted in

-   the same way.

-

-             example

-             a.example

-             yljkjljk.a.example

-             Z.a.example

-             zABC.a.EXAMPLE

-             z.example

-             \001.z.example

-             *.z.example

-             \200.z.example

-

-

-6.2  Canonical RR Form

-

-   For purposes of DNS security, the canonical form of an RR is the wire

-   format of the RR where:

-   1.  Every domain name in the RR is fully expanded (no DNS name

-       compression) and fully qualified;

-   2.  All uppercase US-ASCII letters in the owner name of the RR are

-       replaced by the corresponding lowercase US-ASCII letters;

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 22]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   3.  If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,

-       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,

-       SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in

-       the DNS names contained within the RDATA are replaced by the

-       corresponding lowercase US-ASCII letters;

-   4.  If the owner name of the RR is a wildcard name, the owner name is

-       in its original unexpanded form, including the "*" label (no

-       wildcard substitution); and

-   5.  The RR's TTL is set to its original value as it appears in the

-       originating authoritative zone or the Original TTL field of the

-       covering RRSIG RR.

-

-6.3  Canonical RR Ordering Within An RRset

-

-   For purposes of DNS security, RRs with the same owner name, class,

-   and type are sorted by treating the RDATA portion of the canonical

-   form of each RR as a left-justified unsigned octet sequence where the

-   absence of an octet sorts before a zero octet.

-

-   [RFC2181] specifies that an RRset is not allowed to contain duplicate

-   records (multiple RRs with the same owner name, class, type, and

-   RDATA).  Therefore, if an implementation detects duplicate RRs when

-   putting the RRset in canonical form, the implementation MUST treat

-   this as a protocol error.  If the implementation chooses to handle

-   this protocol error in the spirit of the robustness principle (being

-   liberal in what it accepts), the implementation MUST remove all but

-   one of the duplicate RR(s) for purposes of calculating the canonical

-   form of the RRset.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 23]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-7.  IANA Considerations

-

-   This document introduces no new IANA considerations, because all of

-   the protocol parameters used in this document have already been

-   assigned by previous specifications.  However, since the evolution of

-   DNSSEC has been long and somewhat convoluted, this section attempts

-   to describe the current state of the IANA registries and other

-   protocol parameters which are (or once were) related to DNSSEC.

-

-   Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA

-   considerations.

-

-   DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to

-      the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS

-      Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47,

-      and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. [RFC3755]

-      also marked type 30 (NXT) as Obsolete, and restricted use of types

-      24 (SIG) and 25 (KEY) to the "SIG(0)" transaction security

-      protocol described in [RFC2931] and the transaction KEY Resource

-      Record described in [RFC2930].

-

-   DNS Security Algorithm Numbers: [RFC2535] created an IANA registry

-      for DNSSEC Resource Record Algorithm field numbers, and assigned

-      values 1-4 and 252-255.  [RFC3110] assigned value 5. [RFC3755]

-      altered this registry to include flags for each entry regarding

-      its use with the DNS security extensions.  Each algorithm entry

-      could refer to an algorithm that can be used for zone signing,

-      transaction security (see [RFC2931]) or both. Values 6-251 are

-      available for assignment by IETF standards action. See Appendix A

-      for a full listing of the DNS Security Algorithm Numbers entries

-      at the time of writing and their status of use in DNSSEC.

-

-      [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and

-      assigned value 0 to reserved and value 1 to SHA-1.

-

-   KEY Protocol Values: [RFC2535] created an IANA Registry for KEY

-      Protocol Values, but [RFC3445] re-assigned all values other than 3

-      to reserved and closed this IANA registry.  The registry remains

-      closed, and all KEY and DNSKEY records are required to have

-      Protocol Octet value of 3.

-

-   Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA

-      registry for the DNSSEC KEY and DNSKEY RR flag bits.  Initially,

-      this registry only contains an assignment for bit 7 (the ZONE bit)

-      and a reservation for bit 15 for the Secure Entry Point flag (SEP

-      bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by

-      IETF Standards Action.

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 24]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-8.  Security Considerations

-

-   This document describes the format of four DNS resource records used

-   by the DNS security extensions, and presents an algorithm for

-   calculating a key tag for a public key. Other than the items

-   described below, the resource records themselves introduce no

-   security considerations.  Please see [I-D.ietf-dnsext-dnssec-intro]

-   and [I-D.ietf-dnsext-dnssec-protocol] for additional security

-   considerations related to the use of these records.

-

-   The DS record points to a DNSKEY RR using a cryptographic digest, the

-   key algorithm type and a key tag.  The DS record is intended to

-   identify an existing DNSKEY RR, but it is theoretically possible for

-   an attacker to generate a DNSKEY that matches all the DS fields.  The

-   probability of constructing such a matching DNSKEY depends on the

-   type of digest algorithm in use.  The only currently defined digest

-   algorithm is SHA-1, and the working group believes that constructing

-   a public key which would match the algorithm, key tag, and SHA-1

-   digest given in a DS record would be a sufficiently difficult problem

-   that such an attack is not a serious threat at this time.

-

-   The key tag is used to help select DNSKEY resource records

-   efficiently, but it does not uniquely identify a single DNSKEY

-   resource record.  It is possible for two distinct DNSKEY RRs to have

-   the same owner name, the same algorithm type, and the same key tag.

-   An implementation which uses only the key tag to select a DNSKEY RR

-   might select the wrong public key in some circumstances.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 25]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-9.  Acknowledgments

-

-   This document was created from the input and ideas of the members of

-   the DNS Extensions Working Group and working group mailing list.  The

-   editors would like to express their thanks for the comments and

-   suggestions received during the revision of these security extension

-   specifications.  While explicitly listing everyone who has

-   contributed during the decade during which DNSSEC has been under

-   development would be an impossible task,

-   [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the

-   participants who were kind enough to comment on these documents.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 26]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-10.  References

-

-10.1  Normative References

-

-   [I-D.ietf-dnsext-dnssec-intro]

-              Arends, R., Austein, R., Larson, M., Massey, D. and S.

-              Rose, "DNS Security Introduction and Requirements",

-              draft-ietf-dnsext-dnssec-intro-10 (work in progress), May

-              2004.

-

-   [I-D.ietf-dnsext-dnssec-protocol]

-              Arends, R., Austein, R., Larson, M., Massey, D. and S.

-              Rose, "Protocol Modifications for the DNS Security

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

-              progress), May 2004.

-

-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",

-              STD 13, RFC 1034, November 1987.

-

-   [RFC1035]  Mockapetris, P., "Domain names - implementation and

-              specification", STD 13, RFC 1035, November 1987.

-

-   [RFC1521]  Borenstein, N. and N. Freed, "MIME (Multipurpose Internet

-              Mail Extensions) Part One: Mechanisms for Specifying and

-              Describing the Format of Internet Message Bodies", RFC

-              1521, September 1993.

-

-   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,

-              August 1996.

-

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

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

-

-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic

-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,

-              April 1997.

-

-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS

-              Specification", RFC 2181, July 1997.

-

-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS

-              NCACHE)", RFC 2308, March 1998.

-

-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC

-              2671, August 1999.

-

-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (

-              SIG(0)s)", RFC 2931, September 2000.

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 27]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain

-              Name System (DNS)", RFC 3110, May 2001.

-

-   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY

-              Resource Record (RR)", RFC 3445, December 2002.

-

-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record

-              (RR) Types", RFC 3597, September 2003.

-

-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record

-              (RR)", RFC 3658, December 2003.

-

-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation

-              Signer", RFC 3755, April 2004.

-

-   [RFC3757]  Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure

-              Entry Point Flag", RFC 3757, April 2004.

-

-10.2  Informative References

-

-   [I-D.ietf-dnsext-nsec-rdata]

-              Schlyter, J., "KEY RR Secure Entry Point Flag",

-              draft-ietf-dnsext-nsec-rdata-05 (work in progress), March

-              2004.

-

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

-              RFC 2535, March 1999.

-

-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY

-              RR)", RFC 2930, September 2000.

-

-

-Authors' Addresses

-

-   Roy Arends

-   Telematica Instituut

-   Drienerlolaan 5

-   7522 NB  Enschede

-   NL

-

-   EMail: roy.arends@telin.nl

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 28]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   Rob Austein

-   Internet Systems Consortium

-   950 Charter Street

-   Redwood City, CA  94063

-   USA

-

-   EMail: sra@isc.org

-

-

-   Matt Larson

-   VeriSign, Inc.

-   21345 Ridgetop Circle

-   Dulles, VA  20166-6503

-   USA

-

-   EMail: mlarson@verisign.com

-

-

-   Dan Massey

-   USC Information Sciences Institute

-   3811 N. Fairfax Drive

-   Arlington, VA  22203

-   USA

-

-   EMail: masseyd@isi.edu

-

-

-   Scott Rose

-   National Institute for Standards and Technology

-   100 Bureau Drive

-   Gaithersburg, MD  20899-8920

-   USA

-

-   EMail: scott.rose@nist.gov

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 29]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-Appendix A.  DNSSEC Algorithm and Digest Types

-

-   The DNS security extensions are designed to be independent of the

-   underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS

-   resource records all use a DNSSEC Algorithm Number to identify the

-   cryptographic algorithm in use by the resource record.   The DS

-   resource record also specifies a Digest Algorithm Number to identify

-   the digest algorithm used to construct the DS record. The currently

-   defined Algorithm and Digest Types are listed below.  Additional

-   Algorithm or Digest Types could be added as advances in cryptography

-   warrant.

-

-   A DNSSEC aware resolver or name server MUST implement all MANDATORY

-   algorithms.

-

-A.1  DNSSEC Algorithm Types

-

-   The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify

-   the security algorithm being used.  These values are stored in the

-   "Algorithm number" field in the resource record RDATA.

-

-   Some algorithms are usable only for zone signing (DNSSEC), some only

-   for transaction security mechanisms (SIG(0) and TSIG), and some for

-   both.  Those usable for zone signing may appear in DNSKEY, RRSIG, and

-   DS RRs.  Those usable for transaction security would be present in

-   SIG(0) and KEY RRs as described in [RFC2931]

-

-                                Zone

-   Value Algorithm [Mnemonic]  Signing  References   Status

-   ----- -------------------- --------- ----------  ---------

-     0   reserved

-     1   RSA/MD5 [RSAMD5]         n      RFC 2537   NOT RECOMMENDED

-     2   Diffie-Hellman [DH]      n      RFC 2539    -

-     3   DSA/SHA-1 [DSA]          y      RFC 2536   OPTIONAL

-     4   Elliptic Curve [ECC]              TBA       -

-     5   RSA/SHA-1 [RSASHA1]      y      RFC 3110   MANDATORY

-   252   Indirect [INDIRECT]      n                  -

-   253   Private [PRIVATEDNS]     y      see below  OPTIONAL

-   254   Private [PRIVATEOID]     y      see below  OPTIONAL

-   255   reserved

-

-   6 - 251  Available for assignment by IETF Standards Action.

-

-A.1.1  Private Algorithm Types

-

-   Algorithm number 253 is reserved for private use and will never be

-   assigned to a specific algorithm.  The public key area in the DNSKEY

-   RR and the signature area in the RRSIG RR begin with a wire encoded

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 30]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   domain name, which MUST NOT be compressed. The domain name indicates

-   the private algorithm to use and the remainder of the public key area

-   is determined by that algorithm.  Entities should only use domain

-   names they control to designate their private algorithms.

-

-   Algorithm number 254 is reserved for private use and will never be

-   assigned to a specific algorithm. The public key area in the DNSKEY

-   RR and the signature area in the RRSIG RR begin with an unsigned

-   length byte followed by a BER encoded Object Identifier (ISO OID) of

-   that length.  The OID indicates the private algorithm in use and the

-   remainder of the area is whatever is required by that algorithm.

-   Entities should only use OIDs they control to designate their private

-   algorithms.

-

-A.2  DNSSEC Digest Types

-

-   A "Digest Type" field in the DS resource record types identifies the

-   cryptographic digest algorithm used by the resource record.   The

-   following table lists the currently defined digest algorithm types.

-

-              VALUE   Algorithm                 STATUS

-                0      Reserved                   -

-                1      SHA-1                   MANDATORY

-              2-255    Unassigned                 -

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 31]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-Appendix B.  Key Tag Calculation

-

-   The Key Tag field in the RRSIG and DS resource record types provides

-   a mechanism for selecting a public key efficiently. In most cases, a

-   combination of owner name, algorithm, and key tag can efficiently

-   identify a DNSKEY record.  Both the RRSIG and DS resource records

-   have corresponding DNSKEY records.  The Key Tag field in the RRSIG

-   and DS records can be used to help select the corresponding DNSKEY RR

-   efficiently when more than one candidate DNSKEY RR is available.

-

-   However, it is essential to note that the key tag is not a unique

-   identifier. It is theoretically possible for two distinct DNSKEY RRs

-   to have the same owner name, the same algorithm, and the same key

-   tag. The key tag is used to limit the possible candidate keys, but it

-   does not uniquely identify a DNSKEY record. Implementations MUST NOT

-   assume that the key tag uniquely identifies a DNSKEY RR.

-

-   The key tag is the same for all DNSKEY algorithm types except

-   algorithm 1 (please see Appendix B.1 for the definition of the key

-   tag for algorithm 1).  The key tag algorithm is the sum of the wire

-   format of the DNSKEY RDATA broken into 2 octet groups.  First the

-   RDATA (in wire format) is treated as a series of 2 octet groups,

-   these groups are then added together ignoring any carry bits.

-

-   A reference implementation of the key tag algorithm is as an ANSI C

-   function is given below with the RDATA portion of the DNSKEY RR is

-   used as input.  It is not necessary to use the following reference

-   code verbatim, but the numerical value of the Key Tag MUST be

-   identical to what the reference implementation would generate for the

-   same input.

-

-   Please note that the algorithm for calculating the Key Tag is almost

-   but not completely identical to the familiar ones complement checksum

-   used in many other Internet protocols.  Key Tags MUST be calculated

-   using the algorithm described here rather than the ones complement

-   checksum.

-

-   The following ANSI C reference implementation calculates the value of

-   a Key Tag.  This reference implementation applies to all algorithm

-   types except algorithm 1 (see Appendix B.1).  The input is the wire

-   format of the RDATA portion of the DNSKEY RR.  The code is written

-   for clarity, not efficiency.

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 32]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-   /*

-    * Assumes that int is at least 16 bits.

-    * First octet of the key tag is the most significant 8 bits of the

-    * return value;

-    * Second octet of the key tag is the least significant 8 bits of the

-    * return value.

-    */

-

-   unsigned int

-   keytag (

-           unsigned char key[],  /* the RDATA part of the DNSKEY RR */

-           unsigned int keysize  /* the RDLENGTH */

-          )

-   {

-           unsigned long ac;     /* assumed to be 32 bits or larger */

-           int i;                /* loop index */

-

-           for ( ac = 0, i = 0; i < keysize; ++i )

-                   ac += (i & 1) ? key[i] : key[i] << 8;

-           ac += (ac >> 16) & 0xFFFF;

-           return ac & 0xFFFF;

-   }

-

-

-B.1  Key Tag for Algorithm 1 (RSA/MD5)

-

-   The key tag for algorithm 1 (RSA/MD5) is defined differently than the

-   key tag for all other algorithms, for historical reasons.  For a

-   DNSKEY RR with algorithm 1, the key tag is defined to be the most

-   significant 16 bits of the least significant 24 bits in the public

-   key modulus (in other words, the 4th to last and 3rd to last octets

-   of the public key modulus).

-

-   Please note that Algorithm 1 is NOT RECOMMENDED.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 33]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

-Intellectual Property Statement

-

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

-   intellectual property or other rights that might be claimed to

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

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

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

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

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

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

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

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

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

-   proprietary rights by implementors or users of this specification can

-   be obtained from the IETF Secretariat.

-

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

-   copyrights, patents or patent applications, or other proprietary

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

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

-   Director.

-

-

-Full Copyright Statement

-

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

-

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

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

-   or assist in its implementation may be prepared, copied, published

-   and distributed, in whole or in part, without restriction of any

-   kind, provided that the above copyright notice and this paragraph are

-   included on all such copies and derivative works. However, this

-   document itself may not be modified in any way, such as by removing

-   the copyright notice or references to the Internet Society or other

-   Internet organizations, except as needed for the purpose of

-   developing Internet standards in which case the procedures for

-   copyrights defined in the Internet Standards process must be

-   followed, or as required to translate it into languages other than

-   English.

-

-   The limited permissions granted above are perpetual and will not be

-   revoked by the Internet Society or its successors or assignees.

-

-   This document and the information contained herein is provided on an

-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 34]

-

-Internet-Draft          DNSSEC Resource Records                 May 2004

-

-

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

-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Acknowledgment

-

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

-   Internet Society.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Arends, et al.         Expires November 15, 2004               [Page 35]

-

-

+
+
+DNS Extensions                                                 R. Arends
+Internet-Draft                                      Telematica Instituut
+Expires: January 13, 2005                                     R. Austein
+                                                                     ISC
+                                                               M. Larson
+                                                                VeriSign
+                                                               D. Massey
+                                                                 USC/ISI
+                                                                 S. Rose
+                                                                    NIST
+                                                           July 15, 2004
+
+
+            Resource Records for the DNS Security Extensions
+                  draft-ietf-dnsext-dnssec-records-09
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 13, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document is part of a family of documents that describes the DNS
+   Security Extensions (DNSSEC).  The DNS Security Extensions are a
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 1]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   collection of resource records and protocol modifications that
+   provide source authentication for the DNS.  This document defines the
+   public key (DNSKEY), delegation signer (DS), resource record digital
+   signature (RRSIG), and authenticated denial of existence (NSEC)
+   resource records.  The purpose and format of each resource record is
+   described in detail, and an example of each resource record is given.
+
+   This document obsoletes RFC 2535 and incorporates changes from all
+   updates to RFC 2535.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1   Background and Related Documents . . . . . . . . . . . . .  4
+     1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . . .  5
+     2.1   DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . .  5
+       2.1.1   The Flags Field  . . . . . . . . . . . . . . . . . . .  5
+       2.1.2   The Protocol Field . . . . . . . . . . . . . . . . . .  6
+       2.1.3   The Algorithm Field  . . . . . . . . . . . . . . . . .  6
+       2.1.4   The Public Key Field . . . . . . . . . . . . . . . . .  6
+       2.1.5   Notes on DNSKEY RDATA Design . . . . . . . . . . . . .  6
+     2.2   The DNSKEY RR Presentation Format  . . . . . . . . . . . .  6
+     2.3   DNSKEY RR Example  . . . . . . . . . . . . . . . . . . . .  7
+   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . . .  8
+     3.1   RRSIG RDATA Wire Format  . . . . . . . . . . . . . . . . .  8
+       3.1.1   The Type Covered Field . . . . . . . . . . . . . . . .  9
+       3.1.2   The Algorithm Number Field . . . . . . . . . . . . . .  9
+       3.1.3   The Labels Field . . . . . . . . . . . . . . . . . . .  9
+       3.1.4   Original TTL Field . . . . . . . . . . . . . . . . . . 10
+       3.1.5   Signature Expiration and Inception Fields  . . . . . . 10
+       3.1.6   The Key Tag Field  . . . . . . . . . . . . . . . . . . 10
+       3.1.7   The Signer's Name Field  . . . . . . . . . . . . . . . 11
+       3.1.8   The Signature Field  . . . . . . . . . . . . . . . . . 11
+     3.2   The RRSIG RR Presentation Format . . . . . . . . . . . . . 12
+     3.3   RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12
+   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14
+     4.1   NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14
+       4.1.1   The Next Domain Name Field . . . . . . . . . . . . . . 14
+       4.1.2   The Type Bit Maps Field  . . . . . . . . . . . . . . . 15
+       4.1.3   Inclusion of Wildcard Names in NSEC RDATA  . . . . . . 16
+     4.2   The NSEC RR Presentation Format  . . . . . . . . . . . . . 16
+     4.3   NSEC RR Example  . . . . . . . . . . . . . . . . . . . . . 16
+   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18
+     5.1   DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18
+       5.1.1   The Key Tag Field  . . . . . . . . . . . . . . . . . . 19
+       5.1.2   The Algorithm Field  . . . . . . . . . . . . . . . . . 19
+       5.1.3   The Digest Type Field  . . . . . . . . . . . . . . . . 19
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 2]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+       5.1.4   The Digest Field . . . . . . . . . . . . . . . . . . . 19
+     5.2   Processing of DS RRs When Validating Responses . . . . . . 19
+     5.3   The DS RR Presentation Format  . . . . . . . . . . . . . . 20
+     5.4   DS RR Example  . . . . . . . . . . . . . . . . . . . . . . 20
+   6.  Canonical Form and Order of Resource Records . . . . . . . . . 21
+     6.1   Canonical DNS Name Order . . . . . . . . . . . . . . . . . 21
+     6.2   Canonical RR Form  . . . . . . . . . . . . . . . . . . . . 21
+     6.3   Canonical RR Ordering Within An RRset  . . . . . . . . . . 22
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
+   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 26
+   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 26
+   10.2  Informative References . . . . . . . . . . . . . . . . . . . 27
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
+   A.  DNSSEC Algorithm and Digest Types  . . . . . . . . . . . . . . 29
+     A.1   DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29
+       A.1.1   Private Algorithm Types  . . . . . . . . . . . . . . . 29
+     A.2   DNSSEC Digest Types  . . . . . . . . . . . . . . . . . . . 30
+   B.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . . . . 31
+     B.1   Key Tag for Algorithm 1 (RSA/MD5)  . . . . . . . . . . . . 32
+       Intellectual Property and Copyright Statements . . . . . . . . 33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 3]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+1.  Introduction
+
+   The DNS Security Extensions (DNSSEC) introduce four new DNS resource
+   record types: DNSKEY, RRSIG, NSEC, and DS.  This document defines the
+   purpose of each resource record (RR), the RR's RDATA format, and its
+   presentation format (ASCII representation).
+
+1.1  Background and Related Documents
+
+   The reader is assumed to be familiar with the basic DNS concepts
+   described in [RFC1034], [RFC1035] and subsequent RFCs that update
+   them:  [RFC2136], [RFC2181] and [RFC2308].
+
+   This document is part of a family of documents that define the DNS
+   security extensions.  The DNS security extensions (DNSSEC) are a
+   collection of resource records and DNS protocol modifications that
+   add source authentication and data integrity to the Domain Name
+   System (DNS).  An introduction to DNSSEC and definitions of common
+   terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is
+   assumed to be familiar with this document.  A description of DNS
+   protocol modifications can be found in
+   [I-D.ietf-dnsext-dnssec-protocol].
+
+   This document defines the DNSSEC resource records.
+
+1.2  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 4]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+2.  The DNSKEY Resource Record
+
+   DNSSEC uses public key cryptography to sign and authenticate DNS
+   resource record sets (RRsets).  The public keys are stored in DNSKEY
+   resource records and are used in the DNSSEC authentication process
+   described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its
+   authoritative RRsets using a private key and stores the corresponding
+   public key in a DNSKEY RR.  A resolver can then use the public key to
+   authenticate signatures covering the RRsets in the zone.
+
+   The DNSKEY RR is not intended as a record for storing arbitrary
+   public keys and MUST NOT be used to store certificates or public keys
+   that do not directly relate to the DNS infrastructure.
+
+   The Type value for the DNSKEY RR type is 48.
+
+   The DNSKEY RR is class independent.
+
+   The DNSKEY RR has no special TTL requirements.
+
+2.1  DNSKEY RDATA Wire Format
+
+   The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
+   octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
+   Field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Flags            |    Protocol   |   Algorithm   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Public Key                         /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+2.1.1  The Flags Field
+
+   Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
+   then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner
+   name MUST be the name of a zone.  If bit 7 has value 0, then the
+   DNSKEY record holds some other type of DNS public key and MUST NOT be
+   used to verify RRSIGs that cover RRsets.
+
+   Bit 15 of the Flags field is the Secure Entry Point flag, described
+   in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
+   key intended for use as a secure entry point.  This flag is only
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 5]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   intended to be to a hint to zone signing or debugging software as to
+   the intended use of this DNSKEY record; validators MUST NOT alter
+   their behavior during the signature validation process in any way
+   based on the setting of this bit.  This also means a DNSKEY RR with
+   the SEP bit set would also need the Zone Key flag set in order to
+   legally be able to generate signatures.  A DNSKEY RR with the SEP set
+   and the Zone Key flag not set MUST NOT be used to verify RRSIGs that
+   cover RRsets.
+
+   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
+   creation of the DNSKEY RR, and MUST be ignored upon reception.
+
+2.1.2  The Protocol Field
+
+   The Protocol Field MUST have value 3 and the DNSKEY RR MUST be
+   treated as invalid during signature verification if found to be some
+   value other than 3.
+
+2.1.3  The Algorithm Field
+
+   The Algorithm field identifies the public key's cryptographic
+   algorithm and determines the format of the Public Key field.  A list
+   of DNSSEC algorithm types can be found in Appendix A.1
+
+2.1.4  The Public Key Field
+
+   The Public Key Field holds the public key material.  The format
+   depends on the algorithm of the key being stored and are described in
+   separate documents.
+
+2.1.5  Notes on DNSKEY RDATA Design
+
+   Although the Protocol Field always has value 3, it is retained for
+   backward compatibility with early versions of the KEY record.
+
+2.2  The DNSKEY RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Flag field MUST be represented as an unsigned decimal integer.
+   Given the currently defined flags, the possible values are: 0, 256,
+   or 257.
+
+   The Protocol Field MUST be represented as an unsigned decimal integer
+   with a value of 3.
+
+   The Algorithm field MUST be represented either as an unsigned decimal
+   integer or as an algorithm mnemonic as specified in Appendix A.1.
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 6]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   The Public Key field MUST be represented as a Base64 encoding of the
+   Public Key.  Whitespace is allowed within the Base64 text.  For a
+   definition of Base64 encoding, see [RFC3548].
+
+2.3  DNSKEY RR Example
+
+   The following DNSKEY RR stores a DNS zone key for example.com.
+
+   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
+                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
+                                          kfzj31GajIQKY+5CptLr3buXA10h
+                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
+                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
+                                          742iU/TpPSEDhm2SNKLijfUppn1U
+                                          aNvv4w==  )
+
+   The first four text fields specify the owner name, TTL, Class, and RR
+   type (DNSKEY).  Value 256 indicates that the Zone Key bit (bit 7) in
+   the Flags field has value 1.  Value 3 is the fixed Protocol value.
+   Value 5 indicates the public key algorithm.  Appendix A.1 identifies
+   algorithm type 5 as RSA/SHA1 and indicates that the format of the
+   RSA/SHA1 public key field is defined in [RFC3110].  The remaining
+   text is a Base64 encoding of the public key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 7]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+3.  The RRSIG Resource Record
+
+   DNSSEC uses public key cryptography to sign and authenticate DNS
+   resource record sets (RRsets).  Digital signatures are stored in
+   RRSIG resource records and are used in the DNSSEC authentication
+   process described in [I-D.ietf-dnsext-dnssec-protocol].  A validator
+   can use these RRSIG RRs to authenticate RRsets from the zone.  The
+   RRSIG RR MUST only be used to carry verification material (digital
+   signatures) used to secure DNS operations.
+
+   An RRSIG record contains the signature for an RRset with a particular
+   name, class, and type.  The RRSIG RR specifies a validity interval
+   for the signature and uses the Algorithm, the Signer's Name, and the
+   Key Tag to identify the DNSKEY RR containing the public key that a
+   validator can use to verify the signature.
+
+   Because every authoritative RRset in a zone must be protected by a
+   digital signature, RRSIG RRs must be present for names containing a
+   CNAME RR.  This is a change to the traditional DNS specification
+   [RFC1034] that stated that if a CNAME is present for a name, it is
+   the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
+   MUST exist for the same name as a CNAME resource record in a signed
+   zone.
+
+   The Type value for the RRSIG RR type is 46.
+
+   The RRSIG RR is class independent.
+
+   An RRSIG RR MUST have the same class as the RRset it covers.
+
+   The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
+   covers.  This is an exception to the [RFC2181] rules for TTL values
+   of individual RRs within a RRset: individual RRSIG with the same
+   owner name will have different TTL values if the RRsets they cover
+   have different TTL values.
+
+3.1  RRSIG RDATA Wire Format
+
+   The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
+   1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
+   TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
+   Inception field, a 2 octet Key tag, the Signer's Name field, and the
+   Signature field.
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 8]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Type Covered           |  Algorithm    |     Labels    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Original TTL                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Signature Expiration                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Signature Inception                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Key Tag            |                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Signature                          /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+3.1.1  The Type Covered Field
+
+   The Type Covered field identifies the type of the RRset that is
+   covered by this RRSIG record.
+
+3.1.2  The Algorithm Number Field
+
+   The Algorithm Number field identifies the cryptographic algorithm
+   used to create the signature.  A list of DNSSEC algorithm types can
+   be found in Appendix A.1
+
+3.1.3  The Labels Field
+
+   The Labels field specifies the number of labels in the original RRSIG
+   RR owner name.  The significance of this field is that a validator
+   uses it to determine if the answer was synthesized from a wildcard.
+   If so, it can be used to determine what owner name was used in
+   generating the signature.
+
+   To validate a signature, the validator needs the original owner name
+   that was used to create the signature.  If the original owner name
+   contains a wildcard label ("*"), the owner name may have been
+   expanded by the server during the response process, in which case the
+   validator will need to reconstruct the original owner name in order
+   to validate the signature.  [I-D.ietf-dnsext-dnssec-protocol]
+   describes how to use the Labels field to reconstruct the original
+   owner name.
+
+
+
+Arends, et al.          Expires January 13, 2005                [Page 9]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   The value of the Labels field MUST NOT count either the null (root)
+   label that terminates the owner name or the wildcard label (if
+   present).  The value of the Labels field MUST be less than or equal
+   to the number of labels in the RRSIG owner name.  For example,
+   "www.example.com." has a Labels field value of 3, and
+   "*.example.com." has a Labels field value of 2.  Root (".") has a
+   Labels field value of 0.
+
+   Although the wildcard label is not included in the count stored in
+   the Labels field of the RRSIG RR, the wildcard label is part of the
+   RRset's owner name when generating or verifying the signature.
+
+3.1.4  Original TTL Field
+
+   The Original TTL field specifies the TTL of the covered RRset as it
+   appears in the authoritative zone.
+
+   The Original TTL field is necessary because a caching resolver
+   decrements the TTL value of a cached RRset.  In order to validate a
+   signature, a validator requires the original TTL.
+   [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original
+   TTL field value to reconstruct the original TTL.
+
+3.1.5  Signature Expiration and Inception Fields
+
+   The Signature Expiration and Inception fields specify a validity
+   period for the signature.  The RRSIG record MUST NOT be used for
+   authentication prior to the inception date and MUST NOT be used for
+   authentication after the expiration date.
+
+   Signature Expiration and Inception field values are in POSIX.1 time
+   format: a 32-bit unsigned number of seconds elapsed since 1 January
+   1970 00:00:00 UTC, ignoring leap seconds, in network byte order.  The
+   longest interval which can be expressed by this format without
+   wrapping is approximately 136 years.  An RRSIG RR can have an
+   Expiration field value which is numerically smaller than the
+   Inception field value if the expiration field value is near the
+   32-bit wrap-around point or if the signature is long lived.  Because
+   of this, all comparisons involving these fields MUST use "Serial
+   number arithmetic" as defined in [RFC1982].  As a direct consequence,
+   the values contained in these fields cannot refer to dates more than
+   68 years in either the past or the future.
+
+3.1.6  The Key Tag Field
+
+   The Key Tag field contains the key tag value of the DNSKEY RR that
+   validates this signature, in network byte order.  Appendix B explains
+   how to calculate Key Tag values.
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 10]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+3.1.7  The Signer's Name Field
+
+   The Signer's Name field value identifies the owner name of the DNSKEY
+   RR which a validator is supposed to use to validate this signature.
+   The Signer's Name field MUST contain the name of the zone of the
+   covered RRset.  A sender MUST NOT use DNS name compression on the
+   Signer's Name field when transmitting a RRSIG RR.
+
+3.1.8  The Signature Field
+
+   The Signature field contains the cryptographic signature that covers
+   the RRSIG RDATA (excluding the Signature field) and the RRset
+   specified by the RRSIG owner name, RRSIG class, and RRSIG Type
+   Covered field.  The format of this field depends on the algorithm in
+   use and these formats are described in separate companion documents.
+
+3.1.8.1  Signature Calculation
+
+   A signature covers the RRSIG RDATA (excluding the Signature Field)
+   and covers the data RRset specified by the RRSIG owner name, RRSIG
+   class, and RRSIG Type Covered fields.  The RRset is in canonical form
+   (see Section 6) and the set RR(1),...RR(n) is signed as follows:
+
+         signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
+
+            "|" denotes concatenation;
+
+            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+               with the Signer's Name field in canonical form and
+               the Signature field excluded;
+
+            RR(i) = owner | type | class | TTL | RDATA length | RDATA
+
+               "owner" is the fully qualified owner name of the RRset in
+               canonical form (for RRs with wildcard owner names, the
+               wildcard label is included in the owner name);
+
+               Each RR MUST have the same owner name as the RRSIG RR;
+
+               Each RR MUST have the same class as the RRSIG RR;
+
+               Each RR in the RRset MUST have the RR type listed in the
+               RRSIG RR's Type Covered field;
+
+               Each RR in the RRset MUST have the TTL listed in the
+               RRSIG Original TTL Field;
+
+               Any DNS names in the RDATA field of each RR MUST be in
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 11]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+               canonical form; and
+
+               The RRset MUST be sorted in canonical order.
+
+   See Section 6.2 and Section 6.3 for details on canonical form and
+   ordering of RRsets.
+
+3.2  The RRSIG RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Type Covered field is represented as a RR type mnemonic.  When
+   the mnemonic is not known, the TYPE representation as described in
+   [RFC3597] (section 5) MUST be used.
+
+   The Algorithm field value MUST be represented either as an unsigned
+   decimal integer or as an algorithm mnemonic as specified in Appendix
+   A.1.
+
+   The Labels field value MUST be represented as an unsigned decimal
+   integer.
+
+   The Original TTL field value MUST be represented as an unsigned
+   decimal integer.
+
+   The Signature Expiration Time and Inception Time field values MUST be
+   represented either as seconds since 1 January 1970 00:00:00 UTC or in
+   the form YYYYMMDDHHmmSS in UTC, where:
+      YYYY is the year (0001-9999, but see Section 3.1.5);
+      MM is the month number (01-12);
+      DD is the day of the month (01-31);
+      HH is the hour in 24 hours notation (00-23);
+      mm is the minute (00-59); and
+      SS is the second (00-59).
+
+   The Key Tag field MUST be represented as an unsigned decimal integer.
+
+   The Signer's Name field value MUST be represented as a domain name.
+
+   The Signature field is represented as a Base64 encoding of the
+   signature.  Whitespace is allowed within the Base64 text.  See
+   Section 2.2.
+
+3.3  RRSIG RR Example
+
+   The following RRSIG RR stores the signature for the A RRset of
+   host.example.com:
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 12]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
+                                  20030220173103 2642 example.com.
+                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
+                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
+                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
+                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
+                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
+
+   The first four fields specify the owner name, TTL, Class, and RR type
+   (RRSIG).  The "A" represents the Type Covered field.  The value 5
+   identifies the algorithm used (RSA/SHA1) to create the signature.
+   The value 3 is the number of Labels in the original owner name.  The
+   value 86400 in the RRSIG RDATA is the Original TTL for the covered A
+   RRset.  20030322173103 and 20030220173103 are the expiration and
+   inception dates, respectively.  2642 is the Key Tag, and example.com.
+   is the Signer's Name.  The remaining text is a Base64 encoding of the
+   signature.
+
+   Note that combination of RRSIG RR owner name, class, and Type Covered
+   indicate that this RRSIG covers the "host.example.com" A RRset.  The
+   Label value of 3 indicates that no wildcard expansion was used.  The
+   Algorithm, Signer's Name, and Key Tag indicate this signature can be
+   authenticated using an example.com zone DNSKEY RR whose algorithm is
+   5 and key tag is 2642.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 13]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+4.  The NSEC Resource Record
+
+   The NSEC resource record lists two separate things: the next owner
+   name (in the canonical ordering of the zone) which contains
+   authoritative data or a delegation point NS RRset, and the set of RR
+   types present at the NSEC RR's owner name.  The complete set of NSEC
+   RRs in a zone both indicate which authoritative RRsets exist in a
+   zone and also form a chain of authoritative owner names in the zone.
+   This information is used to provide authenticated denial of existence
+   for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol].
+
+   Because every authoritative name in a zone must be part of the NSEC
+   chain, NSEC RRs must be present for names containing a CNAME RR.
+   This is a change to the traditional DNS specification [RFC1034] that
+   stated that if a CNAME is present for a name, it is the only type
+   allowed at that name.  An RRSIG (see Section 3) and NSEC MUST exist
+   for the same name as a CNAME resource record in a signed zone.
+
+   See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone
+   signer determines precisely which NSEC RRs it needs to include in a
+   zone.
+
+   The type value for the NSEC RR is 47.
+
+   The NSEC RR is class independent.
+
+   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
+   field.  This is in the spirit of negative caching [RFC2308].
+
+4.1  NSEC RDATA Wire Format
+
+   The RDATA of the NSEC RR is as shown below:
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                      Next Domain Name                         /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Type Bit Maps                           /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+4.1.1  The Next Domain Name Field
+
+   The Next Domain field contains the next owner name (in the canonical
+   ordering of the zone) which has authoritative data or contains a
+   delegation point NS RRset; see Section 6.1 for an explanation of
+   canonical ordering.  The value of the Next Domain Name field in the
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 14]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   last NSEC record in the zone is the name of the zone apex (the owner
+   name of the zone's SOA RR).  This indicates that the owner name of
+   the NSEC RR is the last name in the canonical ordering of the zone.
+
+   A sender MUST NOT use DNS name compression on the Next Domain Name
+   field when transmitting an NSEC RR.
+
+   Owner names of RRsets not authoritative for the given zone (such as
+   glue records) MUST NOT be listed in the Next Domain Name unless at
+   least one authoritative RRset exists at the same owner name.
+
+4.1.2  The Type Bit Maps Field
+
+   The Type Bit Maps field identifies the RRset types which exist at the
+   NSEC RR's owner name.
+
+   The RR type space is split into 256 window blocks, each representing
+   the low-order 8 bits of the 16-bit RR type space.  Each block that
+   has at least one active RR type is encoded using a single octet
+   window number (from 0 to 255), a single octet bitmap length (from 1
+   to 32) indicating the number of octets used for the window block's
+   bitmap, and up to 32 octets (256 bits) of bitmap.
+
+   Blocks are present in the NSEC RR RDATA in increasing numerical
+   order.
+
+      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+
+      where "|" denotes concatenation.
+
+   Each bitmap encodes the low-order 8 bits of RR types within the
+   window block, in network bit order.  The first bit is bit 0.  For
+   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+   to RR type 2 (NS), and so forth.  For window block 1, bit 1
+   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set,
+   it indicates that an RRset of that type is present for the NSEC RR's
+   owner name.  If a bit is clear, it indicates that no RRset of that
+   type is present for the NSEC RR's owner name.
+
+   Bits representing pseudo-types MUST be clear, since they do not
+   appear in zone data.  If encountered, they MUST be ignored upon
+   reading.
+
+   Blocks with no types present MUST NOT be included.  Trailing zero
+   octets in the bitmap MUST be omitted.  The length of each block's
+   bitmap is determined by the type code with the largest numerical
+   value, within that block, among the set of RR types present at the
+   NSEC RR's owner name.  Trailing zero octets not specified MUST be
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 15]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   interpreted as zero octets.
+
+   The bitmap for the NSEC RR at a delegation point requires special
+   attention.  Bits corresponding to the delegation NS RRset and the RR
+   types for which the parent zone has authoritative data MUST be set;
+   bits corresponding to any non-NS RRset for which the parent is not
+   authoritative MUST be clear.
+
+   A zone MUST NOT include an NSEC RR for any domain name that only
+   holds glue records.
+
+4.1.3  Inclusion of Wildcard Names in NSEC RDATA
+
+   If a wildcard owner name appears in a zone, the wildcard label ("*")
+   is treated as a literal symbol and is treated the same as any other
+   owner name for purposes of generating NSEC RRs.  Wildcard owner names
+   appear in the Next Domain Name field without any wildcard expansion.
+   [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards
+   on authenticated denial of existence.
+
+4.2  The NSEC RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Next Domain Name field is represented as a domain name.
+
+   The Type Bit Maps field is represented as a sequence of RR type
+   mnemonics.  When the mnemonic is not known, the TYPE representation
+   as described in [RFC3597] (section 5) MUST be used.
+
+4.3  NSEC RR Example
+
+   The following NSEC RR identifies the RRsets associated with
+   alfa.example.com.  and identifies the next authoritative name after
+   alfa.example.com.
+
+   alfa.example.com. 86400 IN NSEC host.example.com. (
+                                   A MX RRSIG NSEC TYPE1234 )
+
+   The first four text fields specify the name, TTL, Class, and RR type
+   (NSEC).  The entry host.example.com.  is the next authoritative name
+   after alfa.example.com.  in canonical order.  The A, MX, RRSIG, NSEC,
+   and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
+   TYPE1234 RRsets associated with the name alfa.example.com.
+
+   The RDATA section of the NSEC RR above would be encoded as:
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 16]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+            0x04 'h'  'o'  's'  't'
+            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
+            0x03 'c'  'o'  'm'  0x00
+            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
+            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x20
+
+   Assuming that the validator can authenticate this NSEC record, it
+   could be used to prove that beta.example.com does not exist, or could
+   be used to prove there is no AAAA record associated with
+   alfa.example.com.  Authenticated denial of existence is discussed in
+   [I-D.ietf-dnsext-dnssec-protocol].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 17]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+5.  The DS Resource Record
+
+   The DS Resource Record refers to a DNSKEY RR and is used in the DNS
+   DNSKEY authentication process.  A DS RR refers to a DNSKEY RR by
+   storing the key tag, algorithm number, and a digest of the DNSKEY RR.
+   Note that while the digest should be sufficient to identify the
+   public key, storing the key tag and key algorithm helps make the
+   identification process more efficient.  By authenticating the DS
+   record, a resolver can authenticate the DNSKEY RR to which the DS
+   record points.  The key authentication process is described in
+   [I-D.ietf-dnsext-dnssec-protocol].
+
+   The DS RR and its corresponding DNSKEY RR have the same owner name,
+   but they are stored in different locations.  The DS RR appears only
+   on the upper (parental) side of a delegation, and is authoritative
+   data in the parent zone.  For example, the DS RR for "example.com" is
+   stored in the "com" zone (the parent zone) rather than in the
+   "example.com" zone (the child zone).  The corresponding DNSKEY RR is
+   stored in the "example.com" zone (the child zone).  This simplifies
+   DNS zone management and zone signing, but introduces special response
+   processing requirements for the DS RR; these are described in
+   [I-D.ietf-dnsext-dnssec-protocol].
+
+   The type number for the DS record is 43.
+
+   The DS resource record is class independent.
+
+   The DS RR has no special TTL requirements.
+
+5.1  DS RDATA Wire Format
+
+   The RDATA for a DS RR consists of a 2 octet Key Tag field, a one
+   octet Algorithm field, a one octet Digest Type field, and a Digest
+   field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Key Tag             |  Algorithm    |  Digest Type  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Digest                             /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 18]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+5.1.1  The Key Tag Field
+
+   The Key Tag field lists the key tag of the DNSKEY RR referred to by
+   the DS record, in network byte order.
+
+   The Key Tag used by the DS RR is identical to the Key Tag used by
+   RRSIG RRs.  Appendix B describes how to compute a Key Tag.
+
+5.1.2  The Algorithm Field
+
+   The Algorithm field lists the algorithm number of the DNSKEY RR
+   referred to by the DS record.
+
+   The algorithm number used by the DS RR is identical to the algorithm
+   number used by RRSIG and DNSKEY RRs.  Appendix A.1 lists the
+   algorithm number types.
+
+5.1.3  The Digest Type Field
+
+   The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
+   RR.  The Digest Type field identifies the algorithm used to construct
+   the digest.  Appendix A.2 lists the possible digest algorithm types.
+
+5.1.4  The Digest Field
+
+   The DS record refers to a DNSKEY RR by including a digest of that
+   DNSKEY RR.
+
+   The digest is calculated by concatenating the canonical form of the
+   fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
+   and then applying the digest algorithm.
+
+     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
+
+      "|" denotes concatenation
+
+     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
+
+
+   The size of the digest may vary depending on the digest algorithm and
+   DNSKEY RR size.  As of the time of writing, the only defined digest
+   algorithm is SHA-1, which produces a 20 octet digest.
+
+5.2  Processing of DS RRs When Validating Responses
+
+   The DS RR links the authentication chain across zone boundaries, so
+   the DS RR requires extra care in processing.  The DNSKEY RR referred
+   to in the DS RR MUST be a DNSSEC zone key.  The DNSKEY RR Flags MUST
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 19]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
+   zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in
+   the validation process.
+
+5.3  The DS RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Key Tag field MUST be represented as an unsigned decimal integer.
+
+   The Algorithm field MUST be represented either as an unsigned decimal
+   integer or as an algorithm mnemonic specified in Appendix A.1.
+
+   The Digest Type field MUST be represented as an unsigned decimal
+   integer.
+
+   The Digest MUST be represented as a sequence of case-insensitive
+   hexadecimal digits.  Whitespace is allowed within the hexadecimal
+   text.
+
+5.4  DS RR Example
+
+   The following example shows a DNSKEY RR and its corresponding DS RR.
+
+   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
+                                             fwJr1AYtsmx3TGkJaNXVbfi/
+                                             2pHm822aJ5iI9BMzNXxeYCmZ
+                                             DRD99WYwYqUSdjMmmAphXdvx
+                                             egXd/M5+X7OrzKBaMbCVdFLU
+                                             Uh6DhweJBjEVv5f2wwjM9Xzc
+                                             nOf+EPbtG9DMBmADjFDc2w/r
+                                             ljwvFw==
+                                             ) ;  key id = 60485
+
+   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
+                                              98631FAD1A292118 )
+
+
+   The first four text fields specify the name, TTL, Class, and RR type
+   (DS).  Value 60485 is the key tag for the corresponding
+   "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
+   used by this "dskey.example.com." DNSKEY RR.  The value 1 is the
+   algorithm used to construct the digest, and the rest of the RDATA
+   text is the digest in hexadecimal.
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 20]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+6.  Canonical Form and Order of Resource Records
+
+   This section defines a canonical form for resource records, a
+   canonical ordering of DNS names, and a canonical ordering of resource
+   records within an RRset.  A canonical name order is required to
+   construct the NSEC name chain.  A canonical RR form and ordering
+   within an RRset are required to construct and verify RRSIG RRs.
+
+6.1  Canonical DNS Name Order
+
+   For purposes of DNS security, owner names are ordered by treating
+   individual labels as unsigned left-justified octet strings.  The
+   absence of a octet sorts before a zero value octet, and upper case
+   US-ASCII letters are treated as if they were lower case US-ASCII
+   letters.
+
+   To compute the canonical ordering of a set of DNS names, start by
+   sorting the names according to their most significant (rightmost)
+   labels.  For names in which the most significant label is identical,
+   continue sorting according to their next most significant label, and
+   so forth.
+
+   For example, the following names are sorted in canonical DNS name
+   order.  The most significant label is "example".  At this level,
+   "example" sorts first, followed by names ending in "a.example", then
+   names ending "z.example".  The names within each level are sorted in
+   the same way.
+
+             example
+             a.example
+             yljkjljk.a.example
+             Z.a.example
+             zABC.a.EXAMPLE
+             z.example
+             \001.z.example
+             *.z.example
+             \200.z.example
+
+
+6.2  Canonical RR Form
+
+   For purposes of DNS security, the canonical form of an RR is the wire
+   format of the RR where:
+   1.  Every domain name in the RR is fully expanded (no DNS name
+       compression) and fully qualified;
+   2.  All uppercase US-ASCII letters in the owner name of the RR are
+       replaced by the corresponding lowercase US-ASCII letters;
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 21]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   3.  If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
+       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
+       SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in
+       the DNS names contained within the RDATA are replaced by the
+       corresponding lowercase US-ASCII letters;
+   4.  If the owner name of the RR is a wildcard name, the owner name is
+       in its original unexpanded form, including the "*" label (no
+       wildcard substitution); and
+   5.  The RR's TTL is set to its original value as it appears in the
+       originating authoritative zone or the Original TTL field of the
+       covering RRSIG RR.
+
+6.3  Canonical RR Ordering Within An RRset
+
+   For purposes of DNS security, RRs with the same owner name, class,
+   and type are sorted by treating the RDATA portion of the canonical
+   form of each RR as a left-justified unsigned octet sequence where the
+   absence of an octet sorts before a zero octet.
+
+   [RFC2181] specifies that an RRset is not allowed to contain duplicate
+   records (multiple RRs with the same owner name, class, type, and
+   RDATA).  Therefore, if an implementation detects duplicate RRs when
+   putting the RRset in canonical form, the implementation MUST treat
+   this as a protocol error.  If the implementation chooses to handle
+   this protocol error in the spirit of the robustness principle (being
+   liberal in what it accepts), the implementation MUST remove all but
+   one of the duplicate RR(s) for purposes of calculating the canonical
+   form of the RRset.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 22]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+7.  IANA Considerations
+
+   This document introduces no new IANA considerations, because all of
+   the protocol parameters used in this document have already been
+   assigned by previous specifications.  However, since the evolution of
+   DNSSEC has been long and somewhat convoluted, this section attempts
+   to describe the current state of the IANA registries and other
+   protocol parameters which are (or once were) related to DNSSEC.
+
+   Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA
+   considerations.
+
+   DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
+      the SIG, KEY, and NXT RRs, respectively.  [RFC3658] assigned DNS
+      Resource Record Type 43 to DS.  [RFC3755] assigned types 46, 47,
+      and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
+      [RFC3755] also marked type 30 (NXT) as Obsolete, and restricted
+      use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
+      security protocol described in [RFC2931] and the transaction KEY
+      Resource Record described in [RFC2930].
+
+   DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
+      for DNSSEC Resource Record Algorithm field numbers, and assigned
+      values 1-4 and 252-255.  [RFC3110] assigned value 5.  [RFC3755]
+      altered this registry to include flags for each entry regarding
+      its use with the DNS security extensions.  Each algorithm entry
+      could refer to an algorithm that can be used for zone signing,
+      transaction security (see [RFC2931]) or both.  Values 6-251 are
+      available for assignment by IETF standards action.  See Appendix A
+      for a full listing of the DNS Security Algorithm Numbers entries
+      at the time of writing and their status of use in DNSSEC.
+
+      [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and
+      assigned value 0 to reserved and value 1 to SHA-1.
+
+   KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
+      Protocol Values, but [RFC3445] re-assigned all values other than 3
+      to reserved and closed this IANA registry.  The registry remains
+      closed, and all KEY and DNSKEY records are required to have
+      Protocol Octet value of 3.
+
+   Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
+      registry for the DNSSEC KEY and DNSKEY RR flag bits.  Initially,
+      this registry only contains an assignment for bit 7 (the ZONE bit)
+      and a reservation for bit 15 for the Secure Entry Point flag (SEP
+      bit) [RFC3757].  Bits 0-6 and 8-14 are available for assignment by
+      IETF Standards Action.
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 23]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+8.  Security Considerations
+
+   This document describes the format of four DNS resource records used
+   by the DNS security extensions, and presents an algorithm for
+   calculating a key tag for a public key.  Other than the items
+   described below, the resource records themselves introduce no
+   security considerations.  Please see [I-D.ietf-dnsext-dnssec-intro]
+   and [I-D.ietf-dnsext-dnssec-protocol] for additional security
+   considerations related to the use of these records.
+
+   The DS record points to a DNSKEY RR using a cryptographic digest, the
+   key algorithm type and a key tag.  The DS record is intended to
+   identify an existing DNSKEY RR, but it is theoretically possible for
+   an attacker to generate a DNSKEY that matches all the DS fields.  The
+   probability of constructing such a matching DNSKEY depends on the
+   type of digest algorithm in use.  The only currently defined digest
+   algorithm is SHA-1, and the working group believes that constructing
+   a public key which would match the algorithm, key tag, and SHA-1
+   digest given in a DS record would be a sufficiently difficult problem
+   that such an attack is not a serious threat at this time.
+
+   The key tag is used to help select DNSKEY resource records
+   efficiently, but it does not uniquely identify a single DNSKEY
+   resource record.  It is possible for two distinct DNSKEY RRs to have
+   the same owner name, the same algorithm type, and the same key tag.
+   An implementation which uses only the key tag to select a DNSKEY RR
+   might select the wrong public key in some circumstances.
+
+   The table of algorithms in Appendix A and the key tag calculation
+   algorithms in Appendix B include the RSA/MD5 algorithm for
+   completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
+   explained in [RFC3110].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 24]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+9.  Acknowledgments
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group and working group mailing list.  The
+   editors would like to express their thanks for the comments and
+   suggestions received during the revision of these security extension
+   specifications.  While explicitly listing everyone who has
+   contributed during the decade during which DNSSEC has been under
+   development would be an impossible task,
+   [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
+   participants who were kind enough to comment on these documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 25]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+10.  References
+
+10.1  Normative References
+
+   [I-D.ietf-dnsext-dnssec-intro]
+              Arends, R., Austein, R., Larson, M., Massey, D. and S.
+              Rose, "DNS Security Introduction and Requirements",
+              draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
+              2004.
+
+   [I-D.ietf-dnsext-dnssec-protocol]
+              Arends, R., Austein, R., Larson, M., Massey, D. and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
+              progress), May 2004.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              August 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+              April 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
+              SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+              Name System (DNS)", RFC 3110, May 2001.
+
+   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 26]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+              Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 3548, July 2003.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer", RFC 3755, April 2004.
+
+   [RFC3757]  Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
+              Entry Point Flag", RFC 3757, April 2004.
+
+10.2  Informative References
+
+   [I-D.ietf-dnsext-nsec-rdata]
+              Schlyter, J., "DNSSEC NSEC RDATA Format",
+              draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
+              2004.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Drienerlolaan 5
+   7522 NB  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 27]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   USC Information Sciences Institute
+   3811 N. Fairfax Drive
+   Arlington, VA  22203
+   USA
+
+   EMail: masseyd@isi.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 28]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+Appendix A.  DNSSEC Algorithm and Digest Types
+
+   The DNS security extensions are designed to be independent of the
+   underlying cryptographic algorithms.  The DNSKEY, RRSIG, and DS
+   resource records all use a DNSSEC Algorithm Number to identify the
+   cryptographic algorithm in use by the resource record.  The DS
+   resource record also specifies a Digest Algorithm Number to identify
+   the digest algorithm used to construct the DS record.  The currently
+   defined Algorithm and Digest Types are listed below.  Additional
+   Algorithm or Digest Types could be added as advances in cryptography
+   warrant.
+
+   A DNSSEC aware resolver or name server MUST implement all MANDATORY
+   algorithms.
+
+A.1  DNSSEC Algorithm Types
+
+   The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify
+   the security algorithm being used.  These values are stored in the
+   "Algorithm number" field in the resource record RDATA.
+
+   Some algorithms are usable only for zone signing (DNSSEC), some only
+   for transaction security mechanisms (SIG(0) and TSIG), and some for
+   both.  Those usable for zone signing may appear in DNSKEY, RRSIG, and
+   DS RRs.  Those usable for transaction security would be present in
+   SIG(0) and KEY RRs as described in [RFC2931]
+
+                                Zone
+   Value Algorithm [Mnemonic]  Signing  References   Status
+   ----- -------------------- --------- ----------  ---------
+     0   reserved
+     1   RSA/MD5 [RSAMD5]         n      RFC 2537   NOT RECOMMENDED
+     2   Diffie-Hellman [DH]      n      RFC 2539    -
+     3   DSA/SHA-1 [DSA]          y      RFC 2536   OPTIONAL
+     4   Elliptic Curve [ECC]              TBA       -
+     5   RSA/SHA-1 [RSASHA1]      y      RFC 3110   MANDATORY
+   252   Indirect [INDIRECT]      n                  -
+   253   Private [PRIVATEDNS]     y      see below  OPTIONAL
+   254   Private [PRIVATEOID]     y      see below  OPTIONAL
+   255   reserved
+
+   6 - 251  Available for assignment by IETF Standards Action.
+
+A.1.1  Private Algorithm Types
+
+   Algorithm number 253 is reserved for private use and will never be
+   assigned to a specific algorithm.  The public key area in the DNSKEY
+   RR and the signature area in the RRSIG RR begin with a wire encoded
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 29]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   domain name, which MUST NOT be compressed.  The domain name indicates
+   the private algorithm to use and the remainder of the public key area
+   is determined by that algorithm.  Entities should only use domain
+   names they control to designate their private algorithms.
+
+   Algorithm number 254 is reserved for private use and will never be
+   assigned to a specific algorithm.  The public key area in the DNSKEY
+   RR and the signature area in the RRSIG RR begin with an unsigned
+   length byte followed by a BER encoded Object Identifier (ISO OID) of
+   that length.  The OID indicates the private algorithm in use and the
+   remainder of the area is whatever is required by that algorithm.
+   Entities should only use OIDs they control to designate their private
+   algorithms.
+
+A.2  DNSSEC Digest Types
+
+   A "Digest Type" field in the DS resource record types identifies the
+   cryptographic digest algorithm used by the resource record.  The
+   following table lists the currently defined digest algorithm types.
+
+              VALUE   Algorithm                 STATUS
+                0      Reserved                   -
+                1      SHA-1                   MANDATORY
+              2-255    Unassigned                 -
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 30]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+Appendix B.  Key Tag Calculation
+
+   The Key Tag field in the RRSIG and DS resource record types provides
+   a mechanism for selecting a public key efficiently.  In most cases, a
+   combination of owner name, algorithm, and key tag can efficiently
+   identify a DNSKEY record.  Both the RRSIG and DS resource records
+   have corresponding DNSKEY records.  The Key Tag field in the RRSIG
+   and DS records can be used to help select the corresponding DNSKEY RR
+   efficiently when more than one candidate DNSKEY RR is available.
+
+   However, it is essential to note that the key tag is not a unique
+   identifier.  It is theoretically possible for two distinct DNSKEY RRs
+   to have the same owner name, the same algorithm, and the same key
+   tag.  The key tag is used to limit the possible candidate keys, but
+   it does not uniquely identify a DNSKEY record.  Implementations MUST
+   NOT assume that the key tag uniquely identifies a DNSKEY RR.
+
+   The key tag is the same for all DNSKEY algorithm types except
+   algorithm 1 (please see Appendix B.1 for the definition of the key
+   tag for algorithm 1).  The key tag algorithm is the sum of the wire
+   format of the DNSKEY RDATA broken into 2 octet groups.  First the
+   RDATA (in wire format) is treated as a series of 2 octet groups,
+   these groups are then added together ignoring any carry bits.
+
+   A reference implementation of the key tag algorithm is as an ANSI C
+   function is given below with the RDATA portion of the DNSKEY RR is
+   used as input.  It is not necessary to use the following reference
+   code verbatim, but the numerical value of the Key Tag MUST be
+   identical to what the reference implementation would generate for the
+   same input.
+
+   Please note that the algorithm for calculating the Key Tag is almost
+   but not completely identical to the familiar ones complement checksum
+   used in many other Internet protocols.  Key Tags MUST be calculated
+   using the algorithm described here rather than the ones complement
+   checksum.
+
+   The following ANSI C reference implementation calculates the value of
+   a Key Tag.  This reference implementation applies to all algorithm
+   types except algorithm 1 (see Appendix B.1).  The input is the wire
+   format of the RDATA portion of the DNSKEY RR.  The code is written
+   for clarity, not efficiency.
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 31]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+   /*
+    * Assumes that int is at least 16 bits.
+    * First octet of the key tag is the most significant 8 bits of the
+    * return value;
+    * Second octet of the key tag is the least significant 8 bits of the
+    * return value.
+    */
+
+   unsigned int
+   keytag (
+           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
+           unsigned int keysize  /* the RDLENGTH */
+          )
+   {
+           unsigned long ac;     /* assumed to be 32 bits or larger */
+           int i;                /* loop index */
+
+           for ( ac = 0, i = 0; i < keysize; ++i )
+                   ac += (i & 1) ? key[i] : key[i] << 8;
+           ac += (ac >> 16) & 0xFFFF;
+           return ac & 0xFFFF;
+   }
+
+
+B.1  Key Tag for Algorithm 1 (RSA/MD5)
+
+   The key tag for algorithm 1 (RSA/MD5) is defined differently than the
+   key tag for all other algorithms, for historical reasons.  For a
+   DNSKEY RR with algorithm 1, the key tag is defined to be the most
+   significant 16 bits of the least significant 24 bits in the public
+   key modulus (in other words, the 4th to last and 3rd to last octets
+   of the public key modulus).
+
+   Please note that Algorithm 1 is NOT RECOMMENDED.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 32]
+
+Internet-Draft          DNSSEC Resource Records                July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Arends, et al.          Expires January 13, 2005               [Page 33]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/doc/draft/draft-ietf-dnsext-insensitive-04.txt
new file mode 100644
index 00000000..4cfd4178
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-insensitive-04.txt
@@ -0,0 +1,639 @@
+
+INTERNET-DRAFT                                    Donald E. Eastlake 3rd
+Clarifies STD0013                                  Motorola Laboratories
+Expires December 2004                                          July 2004
+
+
+
+       Domain Name System (DNS) Case Insensitivity Clarification
+       ------ ---- ------ ----- ---- ------------- -------------
+                 <draft-ietf-dnsext-insensitive-04.txt>
+
+                         Donald E. Eastlake 3rd
+
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNSEXT working group at namedroppers@ops.ietf.org.
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC 2026.  Internet-Drafts are
+   working documents of the Internet Engineering Task Force (IETF), its
+   areas, and its working groups.  Note that other groups may also
+   distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
+   Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+Abstract
+
+   Domain Name System (DNS) names are "case insensitive". This document
+   explains exactly what that means and provides a clear specification
+   of the rules. This clarification should not have any interoperability
+   consequences.
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+Acknowledgements
+
+   The contributions to this document of Rob Austein, Olafur
+   Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
+   Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully
+   acknowledged.
+
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+
+      Acknowledgements...........................................2
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. Case Insensitivity of DNS Labels........................3
+      2.1 Escaping Unusual DNS Label Octets......................3
+      2.2 Example Labels with Escapes............................4
+      3. Name Lookup, Label Types, and CLASS.....................4
+      3.1 Original DNS Label Types...............................5
+      3.2 Extended Label Type Case Insensitivity Considerations..5
+      3.3 CLASS Case Insensitivity Considerations................5
+      4. Case on Input and Output................................6
+      4.1 DNS Output Case Preservation...........................6
+      4.2 DNS Input Case Preservation............................6
+      5. Internationalized Domain Names..........................7
+      6. Security Considerations.................................7
+
+      Copyright and Disclaimer...................................9
+      Normative References.......................................9
+      Informative References....................................10
+      -02 to -03 Changes........................................10
+      -03 to -04 Changes........................................11
+      Author's Address..........................................11
+      Expiration and File Name..................................11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information. Each node in the DNS tree has a name consisting of
+   zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
+   case insensitive fashion. This document clarifies the meaning of
+   "case insensitive" for the DNS.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+2. Case Insensitivity of DNS Labels
+
+   DNS was specified in the era of [ASCII]. DNS names were expected to
+   look like most host names or Internet email address right halves (the
+   part after the at-sign, "@") or be numeric as in the in-addr.arpa
+   part of the DNS name space. For example,
+
+       foo.example.net.
+       aol.com.
+       www.gnu.ai.mit.edu.
+   or  69.2.0.192.in-addr.arpa.
+
+   Case varied alternatives to the above would be DNS names like
+
+       Foo.ExamplE.net.
+       AOL.COM.
+       WWW.gnu.AI.mit.EDU.
+   or  69.2.0.192.in-ADDR.ARPA.
+
+   However, the individual octets of which DNS names consist are not
+   limited to valid ASCII character codes. They are 8-bit bytes and all
+   values are allowed. Many applications, however, interpret them as
+   ASCII characters.
+
+
+
+2.1 Escaping Unusual DNS Label Octets
+
+   In Master Files [STD 13] and other human readable and writable ASCII
+   contexts, an escape is needed for the byte value for period (0x2E,
+   ".") and all octet values outside of the inclusive range of 0x21
+   ("!")  to 0x7E ("~"). That is to say, 0x2E and all octet values in
+   the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
+
+   One typographic convention for octets that do not correspond to an
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+   ASCII printing graphic is to use a back-slash followed by the value
+   of the octet as an unsigned integer represented by exactly three
+   decimal digits.
+
+   The same convention can be used for printing ASCII characters so that
+   they will be treated as a normal label character.  This includes the
+   back-slash character used in this convention itself which can be
+   expressed as \092 or \\ and the special label separator period (".")
+   which can be expressed as and \046 or \.  respectively. It is
+   advisable to avoid using a backslash to quote an immediately
+   following non-printing ASCII character code to avoid implementation
+   difficulties.
+
+   A back-slash followed by only one or two decimal digits is undefined.
+   A back-slash followed by four decimal digits produces two octets, the
+   first octet having the value of the first three digits considered as
+   a decimal number and the second octet being the character code for
+   the fourth decimal digit.
+
+
+
+2.2 Example Labels with Escapes
+
+   The first example below shows embedded spaces and a period (".")
+   within a label. The second one show a 5 octet label where the second
+   octet has all bits zero, the third is a backslash, and the fourth
+   octet has all bits one.
+
+         Donald\032E\.\032Eastlake\0323rd.example.
+   and   a\000\\\255z.example.
+
+
+
+3. Name Lookup, Label Types, and CLASS
+
+   The design decision was made that comparisons on name lookup for DNS
+   queries should be case insensitive [STD 13]. That is to say, a lookup
+   string octet with a value in the inclusive range of 0x41 to 0x5A, the
+   upper case ASCII letters, MUST match the identical value and also
+   match the corresponding value in the inclusive range 0x61 to 0x7A,
+   the lower case ASCII letters. And a lookup string octet with a lower
+   case ASCII letter value MUST similarly match the identical value and
+   also match the corresponding value in the upper case ASCII letter
+   range.
+
+   (Historical Note: the terms "upper case" and "lower case" were
+   invented after movable type.  The terms originally referred to the
+   two font trays for storing, in partitioned areas, the different
+   physical type elements.  Before movable type, the nearest equivalent
+   terms were "majuscule" and "minuscule".)
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+   One way to implement this rule would be, when comparing octets, to
+   subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
+   before the comparison. Such an operation is commonly known as "case
+   folding" but implementation via case folding is not required. Note
+   that the DNS case insensitivity does NOT correspond to the case
+   folding specified in iso-8859-1 or iso-8859-2. For example, the
+   octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
+   contexts, where they are interpreted as the upper and lower case
+   version of "Y" with an acute accent, they might.
+
+
+
+3.1 Original DNS Label Types
+
+   DNS labels in wire encoded names have a type associated with them.
+   The original DNS standard [RFC 1035] had only two types. ASCII
+   labels, with a length of from zero to 63 octets, and indirect labels
+   which consist of an offset pointer to a name location elsewhere in
+   the wire encoding on a DNS message. (The ASCII label of length zero
+   is reserved for use as the name of the root node of the name tree.)
+   ASCII labels follow the ASCII case conventions described herein and,
+   as stated above, can actually contain arbitrary byte values. Indirect
+   labels are, in effect, replaced by the name to which they point which
+   is then treated with the case insensitivity rules in this document.
+
+
+
+3.2 Extended Label Type Case Insensitivity Considerations
+
+   DNS was extended by [RFC 2671] to have additional label type numbers
+   available. (The only such type defined so far is the BINARY type [RFC
+   2673].)
+
+   The ASCII case insensitivity conventions only apply to ASCII labels,
+   that is to say, label type 0x0, whether appearing directly or invoked
+   by indirect labels.
+
+
+
+3.3 CLASS Case Insensitivity Considerations
+
+   As described in [STD 13] and [RFC 2929], DNS has an additional axis
+   for data location called CLASS. The only CLASS in global use at this
+   time is the "IN" or Internet CLASS.
+
+   The handling of DNS label case is not CLASS dependent.
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+4. Case on Input and Output
+
+   While ASCII label comparisons are case insensitive, [STD 13] says
+   case MUST be preserved on output, and preserved when convenient on
+   input. However, this means less than it would appear since the
+   preservation of case on output is NOT required when output is
+   optimized by the use of indirect labels, as explained below.
+
+
+
+4.1 DNS Output Case Preservation
+
+   [STD 13] views the DNS namespace as a node tree. ASCII output is as
+   if a name was marshaled by taking the label on the node whose name is
+   to be output, converting it to a typographically encoded ASCII
+   string, walking up the tree outputting each label encountered, and
+   preceding all labels but the first with a period ("."). Wire output
+   follows the same sequence but each label is wire encoded and no
+   periods inserted. No "case conversion" or "case folding" is done
+   during such output operations, thus "preserving" case.  However, to
+   optimize output, indirect labels may be used to point to names
+   elsewhere in the DNS answer. In determining whether the name to be
+   pointed to, for example the QNAME, is the "same" as the remainder of
+   the name being optimized, the case insensitive comparison specified
+   above is done. Thus such optimization MAY easily destroy the output
+   preservation of case. This type of optimization is commonly called
+   "name compression".
+
+
+
+4.2 DNS Input Case Preservation
+
+   Originally, DNS input came from an ASCII Master File as defined in
+   [STD 13] or a zone transfer.  DNS Dynamic update and incremental zone
+   transfers [RFC 1995] have been added as a source of DNS data [RFC
+   2136, 3007]. When a node in the DNS name tree is created by any of
+   such inputs, no case conversion is done. Thus the case of ASCII
+   labels is preserved if they are for nodes being created. However,
+   when a name label is input for a node that already exist in DNS data
+   being held, the situation is more complex. Implementations may retain
+   the case first input for such a label or allow new input to override
+   the old case or even maintain separate copies preserving the input
+   case.
+
+   For example, if data with owner name "foo.bar.example" is input and
+   then later data with owner name "xyz.BAR.example" is input, the name
+   of the label on the "bar.example" node, i.e. "bar", might or might
+   not be changed to "BAR" or the actual input case could be preserved.
+   Thus later retrieval of data stored under "xyz.bar.example" in this
+   case can easily return data with "xyz.BAR.example".  The same
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+   considerations apply when inputting multiple data records with owner
+   names differing only in case. For example, if an "A" record is stored
+   as the first resourced record under owner name "xyz.BAR.example" and
+   then a second "A" record is stored under "XYZ.BAR.example", the
+   second MAY be stored with the first (lower case initial label) name
+   or the second MAY override the first so that only an upper case
+   initial label is retained or both capitalizations MAY be kept.
+
+   Note that the order of insertion into a server database of the DNS
+   name tree nodes that appear in a Master File is not defined so that
+   the results of inconsistent capitalization in a Master File are
+   unpredictable output capitalization.
+
+
+
+5. Internationalized Domain Names
+
+   A scheme has been adopted for "internationalized domain names" and
+   "internationalized labels" as described in [RFC 3490, 3454, 3491, and
+   3492]. It makes most of [UNICODE] available through a separate
+   application level transformation from internationalized domain name
+   to DNS domain name and from DNS domain name to internationalized
+   domain name. Any case insensitivity that internationalized domain
+   names and labels have varies depending on the script and is handled
+   entirely as part of the transformation described in [RFC 3454] and
+   [RFC 3491] which should be seen for further details.  This is not a
+   part of the DNS as standardized in STD 13.
+
+
+
+6. Security Considerations
+
+   The equivalence of certain DNS label types with case differences, as
+   clarified in this document, can lead to security problems. For
+   example, a user could be confused by believing two domain names
+   differing only in case were actually different names.
+
+   Furthermore, a domain name may be used in contexts other than the
+   DNS.  It could be used as a case sensitive index into some data base
+   system. Or it could be interpreted as binary data by some integrity
+   or authentication code system. These problems can usually be handled
+   by using a standardized or "canonical" form of the DNS ASCII type
+   labels, that is, always mapping the ASCII letter value octets in
+   ASCII labels to some specific pre-chosen case, either upper case or
+   lower case. An example of a canonical form for domain names (and also
+   a canonical ordering for them) appears in Section 8 of [RFC 2535].
+   See also [RFC 3597].
+
+   Finally, a non-DNS name may be stored into DNS with the false
+   expectation that case will always be preserved. For example, although
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+   this would be quite rare, on a system with case sensitive email
+   address local parts, an attempt to store two "RP" records that
+   differed only in case would probably produce unexpected results that
+   might have security implications. That is because the entire email
+   address, including the possibly case sensitive local or left hand
+   part, is encoded into a DNS name in a readable fashion where the case
+   of some letters might be changed on output as described above.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society 2004.  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except
+   as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Normative References
+
+   [ASCII] - ANSI, "USA Standard Code for Information Interchange",
+   X3.4, American National Standards Institute: New York, 1968.
+
+   [RFC 1034, 1035] - See [STD 13].
+
+   [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
+   1996.
+
+   [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
+   Requirement Levels", March 1997.
+
+   [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
+   "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
+
+   [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
+   March 1999.
+
+   [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
+   Update", November 2000.
+
+   [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
+   draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
+
+   [STD 13]
+       - P. Mockapetris, "Domain names - concepts and facilities", RFC
+   1034, November 1987.
+       - P. Mockapetris, "Domain names - implementation and
+   specification", RFC 1035, November 1987.
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+Informative References
+
+   [RFC 1591] - J. Postel, "Domain Name System Structure and
+   Delegation", March 1994.
+
+   [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
+   June 1999.
+
+   [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
+   Name System (DNS) IANA Considerations", September 2000.
+
+   [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
+   1999.
+
+   [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
+   August 1999.
+
+   [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
+   Foo", 1 April 2001.
+
+   [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
+   Internationalized String ("stringprep")", December 2002.
+
+   [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
+   "Internationalizing Domain Names in Applications (IDNA)", March 2003.
+
+   [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
+   for Internationalized Domain Names (IDN)", March 2003.
+
+   [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
+   for Internationalized Domain Names in Applications (IDNA)", March
+   2003.
+
+   [UNICODE] - The Unicode Consortium, "The Unicode Standard",
+   <http://www.unicode.org/unicode/standard/standard.html>.
+
+
+
+-02 to -03 Changes
+
+   The following changes were made between draft version -02 and -03:
+
+   1. Add internationalized domain name section and references.
+
+   2. Change to indicate that later input of a label for an existing DNS
+   name tree node may or may not be normalized to the earlier input or
+   override it or both may be preserved.
+
+   3. Numerous minor wording changes.
+
+
+
+D. Eastlake 3rd                                                [Page 10]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+-03 to -04 Changes
+
+   The following changes were made between draft version -03 and -04:
+
+   1. Change to conform to the new IPR, Copyright, etc., notice
+   requirements.
+
+   2. Change in some section headers for clarity.
+
+   3. Drop section on wildcards.
+
+   4. Add emphasis on loss of case preservation due to name compression.
+
+   5. Add references to RFCs 1995 and 3092.
+
+
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1 508-786-7554 (w)
+                +1 508-634-2066 (h)
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires December 2004.
+
+   Its file name is draft-ietf-dnsext-insensitive-04.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 11]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-mdns-32.txt b/doc/draft/draft-ietf-dnsext-mdns-33.txt
index 50c54bcb..8dcacc8b 100644
--- a/doc/draft/draft-ietf-dnsext-mdns-32.txt
+++ b/doc/draft/draft-ietf-dnsext-mdns-33.txt
@@ -7,8 +7,8 @@
 DNSEXT Working Group                                        Levon Esibov
 INTERNET-DRAFT                                             Bernard Aboba
 Category: Standards Track                                    Dave Thaler
-<draft-ietf-dnsext-mdns-32.txt>                                Microsoft
-25 June 2004
+<draft-ietf-dnsext-mdns-33.txt>                                Microsoft
+18 July 2004
 
 
               Linklocal Multicast Name Resolution (LLMNR)
@@ -16,28 +16,29 @@ Category: Standards Track                                    Dave Thaler
    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I become aware will be disclosed, in accordance with
-   RFC 3667.
+   RFC 3668.
 
    Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
+   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
+   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 current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on November 22, 2004.
+   This Internet-Draft will expire on January 2, 2005.
 
 Copyright Notice
 
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+   Copyright (C) The Internet Society 2004.  All rights reserved.
 
 Abstract
 
@@ -54,14 +55,13 @@ Abstract
 
 
 
-
 Esibov, Aboba & Thaler       Standards Track                    [Page 1]
 
 
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
 Table of Contents
@@ -96,6 +96,7 @@ Table of Contents
 Acknowledgments ..............................................   24
 Authors' Addresses ...........................................   25
 Intellectual Property Statement ..............................   25
+Disclaimer of Validity .......................................   26
 Full Copyright Statement .....................................   26
 
 
@@ -114,14 +115,13 @@ Full Copyright Statement .....................................   26
 
 
 
-
 Esibov, Aboba & Thaler       Standards Track                    [Page 2]
 
 
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
 1.  Introduction
@@ -181,7 +181,7 @@ Esibov, Aboba & Thaler       Standards Track                    [Page 3]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
 1.1.  Requirements
@@ -241,7 +241,7 @@ Esibov, Aboba & Thaler       Standards Track                    [Page 4]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    This may occur via any mechanism, including DHCPv4 [RFC2131] or
@@ -301,7 +301,7 @@ Esibov, Aboba & Thaler       Standards Track                    [Page 5]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
 2.1.  LLMNR packet format
@@ -361,7 +361,7 @@ Esibov, Aboba & Thaler       Standards Track                    [Page 6]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
      LLMNR senders and responders MUST support standard queries (opcode
@@ -421,7 +421,7 @@ Esibov, Aboba & Thaler       Standards Track                    [Page 7]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
      question section of an LLMNR query.  LLMNR responders MUST silently
@@ -481,7 +481,7 @@ Esibov, Aboba & Thaler       Standards Track                    [Page 8]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    responder has another RR as well;  the SOA RR MUST NOT be the only RR
@@ -541,7 +541,7 @@ Esibov, Aboba & Thaler       Standards Track                    [Page 9]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
 [e]  Responders MUST NOT respond using cached data.
@@ -601,7 +601,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 10]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    significantly complicates implementation of LLMNR and would not be
@@ -661,7 +661,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 11]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
@@ -721,7 +721,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 12]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
 2.7.  Retransmission and jitter
@@ -781,7 +781,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 13]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    Due to the TTL minimalization necessary when caching an RRset, all
@@ -841,7 +841,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 14]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    round trip estimates, with exponential backoff.  [RFC1536] Section 4
@@ -901,7 +901,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 15]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    IPv4 hosts can be resolved over IPv4 without LLMNR.  However,  if no
@@ -961,7 +961,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 16]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    There are some scenarios when multiple responders MAY respond to the
@@ -1021,7 +1021,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 17]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    it MUST check whether the response arrived on an interface different
@@ -1081,7 +1081,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 18]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    multiple interfaces, and receives replies from more than one, the
@@ -1141,7 +1141,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 19]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    of both hosts responding to the name 'A'.  Link-local addresses will
@@ -1201,7 +1201,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 20]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    possible for an attacker to spoof a response to a frequent query
@@ -1261,7 +1261,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 21]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
    eliminating the benefits of cache separation. As a result, LLMNR is
@@ -1321,7 +1321,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 22]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
@@ -1381,7 +1381,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 23]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
 [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
@@ -1441,7 +1441,7 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 24]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
 
 Authors' Addresses
@@ -1478,7 +1478,7 @@ Intellectual Property Statement
    might or might not be available; neither does it represent that it
    has made any effort to identify any such rights.  Information on the
    IETF's procedures with respect to rights in standards-track and
-   standards- related documentation can be found in BCP-11.  Copies of
+   standards-related documentation can be found in BCP-11.  Copies of
    claims of rights made available for publication and any assurances of
    licenses to be made available, or the result of an attempt made to
    obtain a general license or permission for the use of such
@@ -1501,34 +1501,25 @@ Esibov, Aboba & Thaler       Standards Track                   [Page 25]
 
 
 
-INTERNET-DRAFT                    LLMNR                     25 June 2004
-
+INTERNET-DRAFT                    LLMNR                     18 July 2004
 
-Full Copyright Statement
 
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+Disclaimer of Validity
 
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.  The limited permissions granted above are perpetual and
-   will not be revoked by the Internet Society or its successors or
-   assigns.  This document and the information contained herein is
-   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
-   INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
 Open Issues
 
    Open issues with this specification are tracked on the following web
@@ -1536,10 +1527,19 @@ Open Issues
 
    http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
 
-Expiration Date
 
-   This memo is filed as <draft-ietf-dnsext-mdns-32.txt>,  and  expires
-   December 22, 2004.
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
new file mode 100644
index 00000000..42c3c0b7
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
@@ -0,0 +1,1321 @@
+
+DNS Operations WG                                                     
+Internet-Draft                                         J. Jeong (ed.) 
+                                                                 ETRI 
+                                                                      
+Expires: January 2005                                    18 July 2004 
+    
+    
+      IPv6 Host Configuration of DNS Server Information Approaches 
+             draft-ietf-dnsop-ipv6-dns-configuration-02.txt 
+    
+    
+Status of this Memo 
+    
+   By submitting this Internet-Draft, I certify that any applicable 
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which we become aware will be disclosed, in accordance 
+   with RFC3668. 
+    
+   Internet-Drafts are working documents of the Internet Engineering 
+   Task Force (IETF), its areas, and its working groups.  Note that 
+   other groups may also distribute working documents as Internet-
+   Drafts. 
+    
+   Internet-Drafts are draft documents valid for a maximum of six 
+   months and may be updated, replaced, or obsoleted by other 
+   documents at any time.  It is inappropriate to use Internet-Drafts 
+   as reference material or to cite them other than as "work in 
+   progress." 
+    
+   The list of current Internet-Drafts can be accessed at 
+   http://www.ietf.org/ietf/1id-abstracts.txt. 
+    
+   The list of Internet-Draft Shadow Directories can be accessed at 
+   http://www.ietf.org/shadow.html. 
+    
+   This Internet-Draft will expire on January 17, 2005. 
+    
+Copyright Notice 
+    
+   Copyright (C) The Internet Society (2004). All Rights Reserved. 
+    
+Abstract 
+    
+   This document describes three approaches for IPv6 recursive DNS 
+   server address configuration.  It details the operational 
+   attributes of three solutions: RA option, DHCPv6 option, and Well-
+   known anycast addresses for recursive DNS servers.  Additionally, 
+   it suggests four deployment scenarios considering multi-solution 
+   resolution.  Therefore, this document will give the audience a 
+
+ 
+ 
+Jeong, et al.             Expires - January 2005              [Page 1] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   guideline of IPv6 DNS configuration to select approaches suitable 
+   for their host DNS configuration. 
+    
+Table of Contents 
+    
+   1. Introduction...................................................3
+   2. Terminology....................................................3
+   3. IPv6 DNS Configuration Approaches..............................3
+      3.1 RA Option..................................................3
+          3.1.1 Advantages...........................................4
+          3.1.2 Disadvantages........................................5
+          3.1.3 Observations.........................................5
+      3.2 DHCPv6 Option..............................................6
+          3.2.1 Advantages...........................................7
+          3.2.2 Disadvantages........................................8
+          3.2.3 Observations.........................................9
+      3.3 Well-known Anycast Addresses...............................9
+          3.3.1 Advantages...........................................9
+          3.3.2 Disadvantages.......................................10
+          3.3.3 Observations........................................10
+   4. Interworking among IPv6 DNS Configuration Approaches..........11
+   5. Deployment Scenarios..........................................12
+      5.1 ISP Network...............................................12
+          5.1.1 RA Option Approach..................................12
+          5.1.2 DHCPv6 Option Approach..............................13
+          5.1.3 Well-known Addresses Approach.......................13
+      5.2 Enterprise Network........................................14
+      5.3 3GPP Network..............................................14
+          5.3.1 Currently Available Mechanisms and Recommendations..15
+          5.3.2 RA Extension........................................16
+          5.3.3 Stateless DHCPv6....................................16
+          5.3.4 Well-known Addresses................................17
+          5.3.5 Recommendations.....................................17
+      5.4 Unmanaged Network.........................................18
+          5.4.1 Case A: Gateway does not provide IPv6 at all........18
+          5.4.2 Case B: A dual-stack gateway connected to a dual-stack
+                        ISP.........................................18
+          5.4.3 Case C: A dual-stack gateway connected to an IPv4-only
+                        ISP.........................................19
+          5.4.4 Case D: A gateway connected to an IPv6-only ISP.....19
+   6. Security Considerations.......................................19
+   7. Acknowledgements..............................................19
+   8. Normative References..........................................20
+   9. Informative References........................................20
+   10. Authors' Addresses...........................................21
+   Intellectual Property Statement..................................23
+   Full Copyright Statement.........................................23
+   Acknowledgement..................................................24
+ 
+ 
+Jeong, et al.             Expires - January 2005              [Page 2] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+    
+1. Introduction 
+    
+   Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address 
+   Autoconfiguration provide ways to configure either fixed or mobile 
+   nodes with one or more IPv6 addresses, default routes and some 
+   other parameters [3][4].  To support access to additional services 
+   in the Internet that are identified by a DNS name, such as a web 
+   server, the configuration of at least one recursive DNS server is 
+   also needed for DNS name resolution. 
+    
+   This document describes three approaches of recursive DNS server 
+   address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 
+   option [5]-[7], and (c) Well-known anycast addresses for recursive 
+   DNS servers [9].  Also, it suggests applicable scenarios for four 
+   kinds of networks: (a) ISP network, (b) Enterprise network, (c) 
+   3GPP network, and (d) Unmanaged network. 
+    
+   This document is just an analysis of each possible approach, and 
+   does not make any recommendation on particular one or on a 
+   combination of particular ones.  Some approaches may even not be 
+   adopted at all as a result of further discussion. 
+    
+   Therefore, the objective of this document is to help the audience 
+   select approaches suitable for IPv6 host configuration of recursive 
+   DNS server. 
+    
+2. Terminology 
+    
+   This document uses the terminology described in [3]-[9].  In 
+   addition, a new term is defined below: 
+    
+   Recursive DNS Server (RDNSS)    A Recursive DNS Server is a name 
+                                   server that offers the recursive 
+                                   service of DNS name resolution. 
+    
+3. IPv6 DNS Configuration Approaches 
+    
+   In this section, the operational attributes of three solutions are 
+   described in detail. 
+     
+3.1 RA Option 
+    
+   RA approach is to define a new ND option called RDNSS option that 
+   contains a recursive DNS server address.  Existing ND transport 
+   mechanisms (i.e., advertisements and solicitations) are used.  This 
+   works in the same way that nodes learn about routers and prefixes, 
+   etc.  An IPv6 host can configure the IPv6 addresses of one or more 
+ 
+ 
+Jeong, et al.             Expires - January 2005              [Page 3] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   RDNSSes via RA message periodically sent by router or solicited by 
+   a Router Solicitation (RS) [8].  This approach needs RDNSS 
+   information to be configured in the routers doing the 
+   advertisements.  The configuration of RDNSS address can be 
+   performed manually by operator or other ways, such as automatic 
+   configuration through DHCPv6 client running on the router.  When 
+   advertising more than one RDNSS options, an RA message includes as 
+   many RDNSS options as RDNSSes.  Through ND protocol and RDNSS 
+   option along with prefix information option, an IPv6 host can 
+   perform its network configuration of its IPv6 address and RDNSS 
+   simultaneously [3][4].  The RA option for RDNSS can be used on any 
+   network that supports the use of ND.  However, RA approach performs
+   poorly in some wireless environments where RA message is used for 
+   IPv6 address autoconfiguration, such as WLAN networks. 
+    
+   The RA approach is useful in some non-WLAN mobile environments 
+   where the addresses of the RDNSSes are changing because the RA 
+   option includes a lifetime field.  This can be configured to a 
+   value that will require the client to time out the entry and switch 
+   over to another RDNSS address [8].  However, from the viewpoint of 
+   implementation, lifetime would seem to make matters a bit more 
+   complex.  Instead of just writing DNS configuration file, such as 
+   resolv.conf for the list of RDNSS addresses, we have to have a 
+   daemon around (or a program that is called at the defined 
+   intervals) that keeps monitoring the lifetime of RDNSSes all the 
+   time. 
+    
+   The preference value of RDNSS, included in RDNSS option, allows 
+   IPv6 hosts to select primary RDNSS among several RDNSSes; this can 
+   be used for load balancing of RDNSSes [8]. 
+    
+3.1.1 Advantages 
+    
+   The RA option for RDNSS has a number of advantages.  These include: 
+    
+   1) The RA option is an extension of existing ND/Autoconfig  
+   mechanisms [3][4], and does not require a change in the base ND 
+   protocol. 
+    
+   2) This approach, like ND, works well on a variety of link types  
+   including point-to-point links, point-to-multipoint, and multi-
+   point (i.e., Ethernet LANs), etc.  RFC2461 [3] states, however, 
+   that there may be some link type on which ND is not possible; on 
+   such a link, some other mechanism will be needed for DNS 
+   configuration. 
+    
+   3) All of the information a host needs to run basic Internet  
+   applications such as email, the web, ftp, etc., can be performed 
+ 
+ 
+Jeong, et al.             Expires - January 2005              [Page 4] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   with the addition of this option to ND and address auto-
+   configuration.  The use of a single mechanism is more reliable and 
+   easier to provide than when the RDNSS information is learned via 
+   another protocol mechanism.  Debugging problems when multiple 
+   protocol mechanisms are being used is harder and much more complex.
+    
+   4) This mechanism works over a broad range of scenarios and 
+   leverages IPv6 ND.  This works well on links that support broadcast
+   reliably (e.g., Ethernet LANs) but not necessarily on other links 
+   (e.g., Wireless LANs).  Also, this works well on links that are 
+   high performance (e.g., Ethernet LANs) and low performance (e.g., 
+   Cellular networks).  In the latter case, combining the RDNSS 
+   information with the other information in the RA, the host can 
+   learn all of the information needed to use most Internet 
+   applications such as the web in a single packet.  This not only 
+   saves bandwidth where this is an issue, but also minimizes the 
+   delay to learn the RDNSS information. 
+    
+   5) The RA approach could be used as a model for other similar types 
+   of configuration information.  New RA options for other server 
+   addresses that are common to all clients on a subnet would be easy 
+   to define.  This includes things like NTP servers, SIP servers, etc.
+    
+3.1.2 Disadvantages 
+    
+   1) ND is mostly implemented in kernel part of operating system.  
+   Therefore, if ND supports the configuration of some additional 
+   services, such as DNS, NTP and SIP servers, ND should be extended 
+   in kernel part.  DHCPv6, however, has more flexibility for 
+   extension of service discovery because it is an application layer 
+   protocol. 
+    
+   2) The current ND framework should be modified due to the 
+   synchronization between another ND cache for RDNSSes in kernel 
+   space and DNS configuration file in user space.  Because it is 
+   unacceptable to write and rewrite the DNS configuration file (e.g.,
+   resolv.conf) from the kernel, another approach is needed.  One 
+   simple approach to solve this is to have a daemon listening to what 
+   the kernel conveys, and to have the daemon do these steps, but such 
+   a daemon is not necessary with the current ND framework. 
+    
+   3) It is necessary to configure RDNSS addresses at least at one 
+   router on every link where this information needs to be configured 
+   by RA option. 
+    
+3.1.3 Observations 
+    
+
+ 
+ 
+Jeong, et al.             Expires - January 2005              [Page 5] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   The proposed RDNSS RA option along with IPv6 ND and Auto-
+   configuration allows a host to obtain all of the information it 
+   needs to access basic Internet services like the web, email, ftp, 
+   etc.  This is preferable in environments where hosts use RAs to 
+   autoconfigure their addresses and all hosts on the subnet share the
+   same router and server addresses.  If the configuration information
+   can be obtained from a single mechanism, it is preferable because 
+   it does not add additional delay, and it uses a minimum of 
+   bandwidth.  Environments like this include homes, public cellular 
+   networks, and enterprise environments where no per host 
+   configuration is needed, but exclude public WLAN hot spots. 
+    
+   DHCPv6 is preferable where it is being used for address 
+   configuration and if there is a need for host specific 
+   configuration [5]-[7].  Environments like this are most likely 
+   enterprise environments where the local administration chooses to 
+   have per host configuration control. 
+    
+   Note: the observation section is based on what the proponents of 
+   each approach think makes a good overall solution. 
+    
+3.2 DHCPv6 Option 
+    
+   DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
+   which a host can obtain a list of IP addresses of recursive DNS 
+   servers [7].  The DNS Recursive Name Server option carries a list 
+   of IPv6 addresses of RDNSSes to which the host may send DNS queries.
+   The DNS servers are listed in the order of preference for use by 
+   the DNS resolver on the host. 
+    
+   The DNS Recursive Name Server option can be carried in any DHCPv6 
+   Reply message, in response to either a Request or an Information-
+   request message.  Thus, the DNS Recursive Name Server option can be
+   used either when DHCPv6 is used for address assignment, or when 
+   DHCPv6 is used only for other configuration information as 
+   stateless DHCPv6 [6]. 
+    
+   Stateless DHCPv6 can be deployed either using DHCPv6 servers 
+   running on general-purpose computers, or on router hardware.  
+   Several router vendors currently implement stateless DHCPv6 servers.
+   Deploying stateless DHCPv6 in routers has the advantage that no 
+   special hardware is required, and should work well for networks 
+   where DHCPv6 is needed for very straightforward configuration of 
+   network devices. 
+    
+   However, routers can also act as DHCPv6 relay agents.  In this case,
+   the DHCPv6 server need not be on the router - it can be on a 
+   general purpose computer.  This has the potential to give the 
+ 
+ 
+Jeong, et al.             Expires - January 2005              [Page 6] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   operator of the DHCPv6 server more flexibility in how the DHCPv6 
+   server responds to individual clients - clients can easily be given
+   different configuration information based on their identity, or for
+   any other reason.  Nothing precludes adding this flexibility to a 
+   router, but generally in current practice, DHCP servers running on 
+   general-purpose hosts tend to have more configuration options than 
+   those that are embedded in routers. 
+    
+   DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 
+   clients that use stateful configuration assignment.  To do this, 
+   the DHCPv6 server sends a Reconfigure message to the client.  The 
+   client validates the Reconfigure message, and then contacts the 
+   DHCPv6 server to obtain updated configuration information.  Using 
+   this mechanism, it is currently possible to propagate new 
+   configuration information to DHCPv6 clients as this information 
+   changes. 
+    
+   The DHC Working Group is currently studying an additional mechanism
+   through which configuration information, including the list of 
+   RDNSSes, can be updated.  The Lifetime Option for DHCPv6 [10], 
+   assigns a lifetime to configuration information obtained through 
+   DHCPv6.  At the expiration of the lifetime, the host contacts the 
+   DHCPv6 server to obtain updated configuration information, 
+   including the list of RDNSSes.  This lifetime gives the network 
+   administrator another mechanism to configure hosts with new RDNSSes
+   by controlling the time at which the host refreshes the list. 
+    
+   The DHC Working Group has also discussed the possibility of 
+   defining an extension to DHCPv6 that would allow the use of 
+   multicast to provide configuration information to multiple hosts 
+   with a single DHCPv6 message.  Because of the lack of deployment 
+   experience, the WG has deferred consideration of multicast DHCPv6 
+   configuration at this time.  Experience with DHCPv4 has not 
+   identified a requirement for multicast message delivery, even in 
+   large service provider networks with tens of thousands of hosts 
+   that may initiate a DHCPv4 message exchange simultaneously. 
+    
+3.2.1 Advantages 
+    
+   The DHCPv6 option for RDNSS has a number of advantages.  These 
+   include: 
+    
+   1) DHCPv6 currently provides a general mechanism for conveying 
+   network configuration information to clients.  So configuring 
+   DHCPv6 servers allows the network administrator to configure 
+   RDNSSes along with the addresses of other network services, as well
+   as location-specific information like time zones. 
+    
+ 
+ 
+Jeong, et al.             Expires - January 2005              [Page 7] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   2) As a consequence, when the network administrator goes to 
+   configure DHCPv6, all the configuration information can be managed 
+   through a single service, typically with a single user interface 
+   and a single configuration database. 
+    
+   3) DHCPv6 allows for the configuration of a host with information 
+   specific to that host, so that hosts on the same link can be  
+   configured with different RDNSSes as well as other configuration 
+   information.  This capability is important in some network 
+   deployments such as service provider networks or WiFi hot spots. 
+    
+   4) A mechanism exists for extending DHCPv6 to support the 
+   transmission of additional configuration that has not yet been 
+   anticipated. 
+    
+   5) Hosts that require other configuration information such as the 
+   addresses of SIP servers and NTP servers are likely to need DHCPv6 
+   for other configuration information. 
+    
+   6) The specification for configuration of RDNSSes through DHCPv6 is
+   available as an RFC.  No new protocol extensions such as new 
+   options are necessary. 
+    
+   7) Interoperability among independent implementations has been 
+   demonstrated. 
+    
+3.2.2 Disadvantages 
+    
+   The DHCPv6 option for RDNSS has a few disadvantages.  These 
+   include: 
+    
+   1) Update currently requires message from server (however, see 
+   [10]). 
+    
+   2) Because DNS information is not contained in RA message, the host
+   must receive two messages from the router, and must transmit at  
+   least one message to the router.  On networks where bandwidth is at
+   a premium, this is a disadvantage, although on most networks it is 
+   not a practical concern. 
+    
+   3) Increased latency for initial configuration - in addition to  
+   waiting for an RA message, the client must now exchange packets  
+   with a DHCPv6 server; even if it is locally installed on a router,  
+   this will slightly extend the time required to configure the client.
+   For clients that are moving rapidly from one network to another, 
+   this will be a disadvantage. 
+    
+
+ 
+ 
+Jeong, et al.             Expires - January 2005              [Page 8] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+3.2.3 Observations 
+    
+   In the general case, on general-purpose networks, stateless DHCPv6 
+   provides significant advantages and no significant disadvantages.  
+   Even in the case where bandwidth is at a premium and low latency is
+   desired, if hosts require other configuration information in 
+   addition to a list of RDNSSes or if hosts must be configured 
+   selectively, those hosts will use DHCPv6 and the use of the DHCPv6 
+   DNS recursive name server option will be advantageous. 
+    
+   However, we are aware of some applications where it would be 
+   preferable to put the RDNSS information into an RA packet; for 
+   example, on a cell phone network, where bandwidth is at a premium 
+   and extremely low latency is desired.  The final DNS configuration 
+   draft should be written so as to allow these special applications 
+   to be handled using DNS information in the RA packet. 
+    
+3.3 Well-known Anycast Addresses 
+    
+   First of all, the well-known anycast addresses approach is much 
+   different from that discussed in IPv6 Working Group in the past. 
+    
+   The approach with well-known anycast addresses is to set well-known
+   anycast addresses in clients' resolver configuration files from the
+   beginning, say, as factory default.  Thus, there is no transport 
+   mechanism and no packet format [9]. 
+    
+   An anycast address is an address shared by multiple servers (in 
+   this case, the servers are RDNSSes).  Request from a client to the 
+   anycast address is routed to a server selected by the routing 
+   system.  However, it is a bad idea to mandate "site" boundary on 
+   anycast addresses, because most users just do not have their own 
+   servers and want to access their ISPs' across their site boundaries.
+   Larger sites may also depend on their ISPs or may have their own 
+   RDNSSes within "site" boundaries. 
+    
+   It should be noted that "anycast" in this memo is simpler than that
+   of RFC1546 [11] and RFC3513 [12] where it is assumed to be 
+   prohibited to have multiple servers on a single link sharing an 
+   anycast address.  That is, on a link, anycast address is assumed to 
+   be unique.  DNS clients today already have redundancy by having 
+   multiple well-known anycast addresses configured as RDNSS addresses.
+   There is no point to have multiple RDNSSes sharing an anycast 
+   address on a single link. 
+    
+3.3.1 Advantages 
+    
+
+ 
+ 
+Jeong, et al.             Expires - January 2005              [Page 9] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   The basic advantage of the well-known addresses approach is that it
+   uses no transport mechanism.  Thus, 
+   1) There is no delay to get response and no further delay by packet
+   losses. 
+    
+   2) The approach can be combined with any other configuration 
+   mechanisms including but not limited to factory default 
+   configuration, RA-based approach and DHCP based approach. 
+    
+   3) The approach works over any environment where DNS works. 
+    
+   Another advantage is that the approach needs to configure DNS 
+   servers as a router, but nothing else.  Considering that DNS 
+   servers do need configuration, the amount of overall configuration 
+   effort is proportional to the number of the DNS servers and scales 
+   linearly.  It should be noted that, in the simplest case where a 
+   subscriber to an ISP does not have any DNS server, the subscriber 
+   naturally access DNS servers of the ISP even though the subscriber 
+   and the ISP do nothing and there is no protocol to exchange DNS 
+   server information between the subscriber and the ISP. 
+    
+3.3.2 Disadvantages 
+    
+   Well-known anycast addresses approach requires that DNS servers (or
+   routers near it as a proxy) act as routers to advertise their 
+   anycast addresses to the routing system, which requires some 
+   configuration (see the last paragraph of the previous section on 
+   the scalability of the effort). 
+    
+3.3.3 Observations 
+    
+   If other approaches are used in addition, the well-known anycast 
+   addresses should also be set in RA or DHCP configuration files to 
+   reduce configuration effort of users.
+    
+   Redundancy by multiple RDNSSes is better provided by multiple 
+   servers having different anycast addresses than multiple servers 
+   sharing same anycast address because the former approach allows 
+   stale servers to still generate routes to their anycast addresses. 
+   Thus, in a routing domain (or domains sharing DNS servers), there 
+   will be only one server having an anycast address unless the domain
+   is so large that load distribution is necessary. 
+    
+   Small ISPs will operate one RDNSS at each anycast address which is 
+   shared by all the subscribers.  Large ISPs may operate multiple 
+   RDNSSes at each anycast address to distribute and reduce load, 
+   where boundary between RDNSSes may be fixed (redundancy is still 
+   provided by multiple addresses) or change dynamically.  DNS packets
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 10] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   with the well-known anycast addresses are not expected (though not 
+   prohibited) to cross ISP boundaries, as ISPs are expected to be 
+   able to take care of themselves. 
+    
+   Because "anycast" in this memo is simpler than that of RFC1546 [11]
+   and RFC3513 [12] where it is assumed to be administratively 
+   prohibited to have multiple servers on a single link sharing an 
+   anycast address, anycast in this memo should be implemented as 
+   UNICAST of RFC2461 [3] and RFC3513 [12].  As a result, ND-related 
+   instability disappears.  Thus, anycast in well-known anycast 
+   addresses approach can and should use the anycast address as a 
+   source unicast (according to RFC3513 [12]) address of packets of 
+   UDP and TCP responses.  With TCP, if route flips and packets to an 
+   anycast address are routed to a new server, it is expected that the
+   flip is detected by ICMP or sequence number inconsistency and the 
+   TCP connection is reset and retried.
+    
+4. Interworking among IPv6 DNS Configuration Approaches 
+    
+   Three approaches can work together for IPv6 host configuration of 
+   RDNSS.  This section shows a consideration on how these approaches 
+   can interwork each other. 
+    
+   For ordering between RA and DHCP approaches, O (Other stateful 
+   configuration) flag in RA message can be used [8].  If no RDNSS 
+   option is included, an IPv6 Host may perform DNS configuration 
+   through DHCPv6 [5]-[7] regardless of whether the O flag is set or 
+   not. 
+    
+   The well-known anycast addresses approach fully interworks with the
+   other approaches.  That is, the other approaches can remove 
+   configuration effort on servers by using the well-known addresses 
+   as the default configuration.  Moreover, clients preconfigured with
+   well-known anycast addresses can be further configured to use other
+   approaches to override the well-known addresses, if configuration 
+   information from other approaches are available.  That is, all the 
+   clients should have the well-known anycast addresses preconfigured,
+   in the case where there are no other mechanisms available.  In 
+   order to fly anycast approach with the other solutions, there are 
+   three options. 
+    
+   The first option is that well-known addresses are used as last 
+   resort, when an IPv6 host can not get RDNSS information through RA 
+   and DHCP.  The well-known anycast addresses have to be pre-
+   configured in IPv6 hosts' resolver configuration files. 
+    
+
+
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 11] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   The second is that an IPv6 host can configure well-known addresses 
+   as the most preferable in its configuration file even though either
+   RA option or DHCP option is available. 
+    
+   The last is that the well-known anycast addresses can be set in RA 
+   or DHCP configuration to reduce configuration effort of users.  
+   According to either RA or DHCP mechanism, the well-known addresses 
+   can be obtained by IPv6 host.  Because this approach is the most 
+   convenient for users, the last option is recommended. 
+ 
+   Note: this section does not necessarily mean this document suggests
+   adopting all these three approaches and making them interwork in 
+   the way described here.  In fact, some approaches may even not be 
+   adopted at all as a result of further discussion. 
+    
+5. Deployment Scenarios 
+    
+   Regarding DNS configuration on the IPv6 host, several mechanisms 
+   have being considered at the DNSOP Working Group such as RA option,
+   DHCPv6 option and well-known preconfigured anycast addresses as of 
+   today, and this document is a final result from the long thread.  
+   In this section, we suggest four applicable scenarios of three 
+   approaches for IPv6 DNS configuration. 
+    
+   Note: in the applicable scenarios, authors do not implicitly push 
+   any specific approaches into the restricted environments.  No 
+   enforcement is in each scenario and all mentioned scenarios are 
+   probable.  The main objective of this work is to provide a useful 
+   guideline of IPv6 DNS configuration. 
+    
+5.1 ISP Network 
+    
+   A characteristic of ISP network is that multiple Customer Premises 
+   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) 
+   routers and each PE connects multiple CPE devices to the backbone 
+   network infrastructure [13].  The CPEs may be hosts or routers. 
+    
+   In the case where the CPE is a router, there is a customer network 
+   that is connected to the ISP backbone through the CPE.  Typically, 
+   each customer network gets a different IPv6 prefix from an IPv6 PE 
+   router, but the same RDNSS configuration will be distributed. 
+    
+   This section discusses how the different approaches to distributing
+   DNS information are compared in an ISP network. 
+    
+5.1.1 RA Option Approach 
+    
+
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 12] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   When the CPE is a host, the RA option for RDNSS can be used to 
+   allow the CPE to get RDNSS information as well as /64 prefix 
+   information for stateless address autoconfiguration at the same 
+   time when the host is attached to a new subnet [8].  Because an 
+   IPv6 host must receive at least one RA message for stateless 
+   address autoconfiguration and router configuration, the host could 
+   receive RDNSS configuration information in that RA without the 
+   overhead of an additional message exchange. 
+    
+   When the CPE is a router, the CPE may accept the RDNSS information 
+   from the RA on the interface connected to the ISP, and copy that 
+   information into the RAs advertised in the customer network. 
+    
+   This approach is more valuable in the mobile host scenario, in 
+   which the host must receive at least an RA message for detecting a 
+   new network, than in other scenarios generally although 
+   administrator should configure RDNSS information on the routers.  
+   Secure ND [14] can provide extended security when using RA message.
+    
+5.1.2 DHCPv6 Option Approach 
+    
+   DHCPv6 can be used for RDNSS configuration through the use of the 
+   DNS option, and can provide other configuration information in the 
+   same message with RDNSS configuration [5]-[7].  DHCPv6 DNS option 
+   is already in place for DHCPv6 as RFC 3646 [7] and moreover DHCPv6-
+   lite or stateless DHCP [6] is nowhere as complex as a full DHCPv6 
+   implementation.  DHCP is a client-server model protocol, so ISP can
+   handle user identification on its network intentionally, and also 
+   authenticated DHCP [15] can be used for secure message exchange. 
+    
+   The expected model for deployment of IPv6 service by ISPs is to 
+   assign a prefix to each customer, which will be used by the 
+   customer gateway to assign a /64 prefix to each network in the 
+   customer's network.  Prefix delegation with DHCP (DHCPv6 PD) has 
+   already been adopted by ISPs for automating the assignment of the 
+   customer prefix to the customer gateway [17].  DNS configuration 
+   can be carried in the same DHCPv6 message exchange used for DHCPv6 
+   to efficiently provide that information, along with any other 
+   configuration information needed by the customer gateway or 
+   customer network.  This service model can be useful to Home or SOHO
+   subscribers.  The Home or SOHO gateway, which is a customer gateway
+   for ISP, can then pass that RDNSS configuration information to the 
+   hosts in the customer network through DHCP. 
+    
+5.1.3 Well-known Addresses Approach 
+    
+   Well-known anycast addresses approach is also a feasible and simple
+   mechanism for ISP [9].  The use of well-known anycast addresses 
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 13] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   avoids some of the security risks in rogue messages sent through an
+   external protocol like RA or DHCPv6.  The configuration of hosts 
+   for the use of well-known anycast addresses requires no protocol or
+   manual configuration, but the configuration of routing for the 
+   anycast addresses requires intervention on the part of the network
+   administrator.  Also, the number of special addresses would be 
+   equal to the number of RDNSSes that could be made available to 
+   subscribers. 
+    
+5.2 Enterprise Network 
+    
+   Enterprise network is defined as a network that has multiple 
+   internal links, one or more router connections, to one or more 
+   Providers and is actively managed by a network operations entity 
+   [16].  An enterprise network can get network prefixes from ISP by 
+   either manual configuration or prefix delegation [17].  In most 
+   cases, because an enterprise network manages its own DNS domains, 
+   it operates its own DNS servers for the domains.  These DNS servers
+   within enterprise network process recursive DNS name resolution 
+   requests of IPv6 hosts as RDNSS.  RDNSS configuration in enterprise
+   network can be performed like in Section 4, in which three 
+   approaches can be used together. 
+    
+   IPv6 host can decide which approach is or may be used in its subnet
+   with O flag in RA message [8].  As the first option in Section 4, 
+   well-known anycast addresses can be used as a last resort when 
+   RDNSS information can not be obtained through either RA option or 
+   DHCP option.  This case needs IPv6 hosts to preconfigure the well-
+   known anycast addresses in their DNS configuration files. 
+    
+   When the enterprise prefers well-known anycast approach to the 
+   others, IPv6 hosts should preconfigure the well-known anycast 
+   addresses like in the first option. 
+    
+   The last option, a more convenient and transparent way, does not 
+   need IPv6 hosts to preconfigure the well-known anycast addresses 
+   because the addresses are delivered to IPv6 hosts through either RA
+   option or DHCPv6 option as if they were unicast addresses.  This 
+   way is most recommended for the sake of user's convenience. 
+    
+5.3 3GPP Network 
+    
+   IPv6 DNS configuration is a missing part of IPv6 autoconfiguration 
+   and an important part of the basic IPv6 functionality in the 3GPP 
+   User Equipment (UE).  Higher level description of the 3GPP 
+   architecture can be found in [18], and transition to IPv6 in 3GPP 
+   networks is analyzed in [19] and [20]. 
+    
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 14] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   In 3GPP architecture, there is a dedicated link between the UE and 
+   the GGSN called the Packet Data Protocol (PDP) Context.  This link 
+   is created through the PDP Context activation procedure [21].  
+   There is a separate PDP context type for IPv4 and IPv6 traffic.  If
+   a 3GPP UE user is communicating using IPv6 (having an active IPv6 
+   PDP context), it can not be assumed that (s)he has simultaneously 
+   active IPv4 PDP context, and DNS queries could be done using IPv4. 
+   A 3GPP UE can thus be an IPv6 node, and it needs to somehow 
+   discover the address of the RDNSS.  Before IP-based services (e.g.,
+   web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS 
+   addresses need to be discovered in the 3GPP UE. 
+    
+   Section 5.3.1 briefly summarizes currently available mechanisms in 
+   3GPP networks and recommendations.  5.3.2 analyzes the Router  
+   Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 
+   mechanism, and 5.3.4 analyzes the Well-known addresses approach.  
+   Section 5.3.5 finally summarizes the recommendations. 
+    
+5.3.1 Currently Available Mechanisms and Recommendations 
+    
+   3GPP has defined a mechanism, in which RDNSS addresses can be  
+   received in the PDP context activation (a control plane mechanism).
+   That is called the Protocol Configuration Options Information  
+   Element (PCO-IE) mechanism [22].  The RDNSS addresses can also be 
+   received over the air (using text messages), or typed in manually 
+   in the UE.  Note that the two last mechanisms are not very well  
+   scalable.  The UE user most probably does not want to type IPv6 
+   RDNSS addresses manually in his/her UE.  The use of well-known 
+   addresses is briefly discussed in section 5.3.4. 
+    
+   It is seen that the mechanisms above most probably are not  
+   sufficient for the 3GPP environment.  IPv6 is intended to operate 
+   in a zero-configuration manner, no matter what the underlying 
+   network infrastructure is.  Typically, the RDNSS address is needed 
+   to make an IPv6 node operational - and the DNS configuration should
+   be as simple as the address autoconfiguration mechanism.  It must 
+   also be noted that there will be additional IP interfaces in some 
+   near future 3GPP UEs, e.g., Wireless LAN (WLAN), and 3GPP-specific 
+   DNS configuration mechanisms (such as PCO-IE [22]) do not work for 
+   those IP interfaces.  In other words, a good IPv6 DNS configuration
+   mechanism should also work in a multi-access network environment. 
+    
+   From 3GPP point of view, the best IPv6 DNS configuration solution 
+   is feasible for a very large number of IPv6-capable UEs (can be 
+   even hundreds of millions in one operator's network), is automatic 
+   and thus requires no user action.  It is suggested to standardize a
+   lightweight, stateless mechanism that works in all network  
+   environments.  The solution could then be used for 3GPP, 3GPP2, 
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 15] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   WLAN and other access network technologies.  A light, stateless 
+   IPv6 DNS configuration mechanism is thus not only needed in 3GPP 
+   networks, but also 3GPP networks and UEs would certainly benefit 
+   from the new mechanism. 
+    
+5.3.2 RA Extension 
+    
+   Router Advertisement extension [8] is a lightweight IPv6 DNS  
+   configuration mechanism that requires minor changes in 3GPP UE IPv6
+   stack and Gateway GPRS Support Node (GGSN, the default router in  
+   the 3GPP architecture) IPv6 stack.  This solution can be specified 
+   in the IETF (no action needed in the 3GPP) and taken in use in 3GPP 
+   UEs and GGSNs. 
+    
+   In this solution, an IPv6-capable UE configures DNS information  
+   via RA message sent by its default router (GGSN), i.e., RDNSS 
+   option for recursive DNS server is included in the RA message.  
+   This solution is easily scalable for a very large number of UEs.  
+   The operator can configure the RDNSS addresses in the GGSN as a 
+   part of normal GGSN configuration.  The IPv6 RDNSS address is 
+   received in the Router Advertisement, and an extra Round Trip Time
+   (RTT) for asking RDNSS addresses can be avoided. 
+    
+   If thinking about cons, this mechanism still requires 
+   standardization effort in the IETF, and the end nodes and routers 
+   need to support this mechanism.  The equipment software update 
+   should, however, be pretty straightforward, and new IPv6 equipment 
+   could support RA extension already from the beginning. 
+    
+5.3.3 Stateless DHCPv6 
+    
+   DHCPv6-based solution needs the implementation of Stateless DHCP  
+   [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in  
+   the operator's network.  A possible configuration is such that the
+   GGSN works as a DHCP relay. 
+    
+   Pros for Stateless DHCPv6-based solution are 
+   1) Stateless DHCPv6 is a standardized mechanism. 
+    
+   2) DHCPv6 can be used for receiving other configuration information
+   than RDNSS addresses, e.g., SIP server addresses. 
+    
+   3) DHCPv6 works in different network environments. 
+    
+   4) When DHCPv6 service is deployed through a single, centralized 
+   server, the RDNSS configuration information can be updated by the 
+   network administrator at a single source. 
+    
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 16] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   Some issues with DHCPv6 in 3GPP networks are listed below: 
+   1) DHCPv6 requires an additional server in the network unless the 
+   (Stateless) DHCPv6 functionality is integrated into an existing 
+   router already, and it is one box more to be maintained. 
+    
+   2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing 
+   (3GPP Stateless Address Autoconfiguration is typically used), and 
+   not automatically implemented in 3GPP IPv6 UEs. 
+    
+   3) Scalability and reliability of DHCPv6 in very large 3GPP 
+   networks (with tens or hundreds of millions of UEs) may be an issue,
+   at least the redundancy needs to be taken care of.  However, if the 
+   DHCPv6 service is integrated into the network elements, such as 
+   router operating system, scalability and reliability is comparable 
+   with other DNS configuration approaches. 
+    
+   4) It is sub-optimal to utilize the radio resources in 3GPP 
+   networks for DHCPv6 messages if there is a simpler alternative 
+   available. 
+    
+      a) Use of Stateless DHCPv6 adds one round trip delay to the case
+      in which the UE can start transmitting data right after the 
+      Router Advertisement. 
+    
+   5) If the DNS information (suddenly) changes, Stateless DHCPv6 can 
+   not automatically update the UE, see [23]. 
+    
+5.3.4 Well-known Addresses 
+    
+   Using well-known addresses is also a feasible and a light mechanism
+   for 3GPP UEs.  Those well-known addresses can be preconfigured in  
+   the UE software and the operator makes the corresponding  
+   configuration on the network side.  So this is a very easy 
+   mechanism for the UE, but requires some configuration work in the 
+   network.  When using well-known addresses, UE forwards queries to 
+   any of the preconfigured addresses.  In the current proposal [9], 
+   IPv6 anycast addresses are suggested. 
+    
+   Note: IPv6 DNS configuration proposal based on the use of well-
+   known site-local addresses developed at the IPv6 Working Group was
+   seen as a feasible mechanism for 3GPP UEs, but opposition by some 
+   people in the IETF and finally deprecating IPv6 site-local 
+   addresses made it impossible to standardize it.  Note that this 
+   mechanism is implemented in some existing operating systems today 
+   (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration.
+    
+5.3.5 Recommendations  
+    
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 17] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   It is suggested that a lightweight, stateless DNS configuration 
+   mechanism is specified as soon as possible.  From 3GPP UE's and 
+   networks' point of view, Router Advertisement based mechanism looks
+   most promising.  The sooner a light, stateless mechanism is 
+   specified, the sooner we can get rid of using well-known site-local
+   addresses for IPv6 DNS configuration. 
+    
+5.4 Unmanaged Network 
+    
+   There are 4 deployment scenarios of interest in unmanaged networks 
+   [24]: 
+    
+   1) A gateway which does not provide IPv6 at all; 
+    
+   2) A dual-stack gateway connected to a dual-stack ISP; 
+    
+   3) A dual-stack gateway connected to an IPv4-only ISP; and 
+    
+   4) A gateway connected to an IPv6-only ISP. 
+    
+5.4.1 Case A: Gateway does not provide IPv6 at all 
+    
+   In this case, the gateway does not provide IPv6; the ISP may or may
+   not provide IPv6.  Automatic or Configured tunnels are the 
+   recommended transition mechanisms for this scenario. 
+    
+   The case where dual-stack hosts behind an NAT, that need access to 
+   an IPv6 RDNSS, can not be entirely ruled out.  The DNS 
+   configuration mechanism has to work over the tunnel, and the 
+   underlying tunneling mechanism could be implementing NAT traversal.
+   The tunnel server assumes the role of a relay (both for DHCP and 
+   Well-known anycast addresses approaches). 
+    
+   RA-based mechanism is relatively straightforward in its operation, 
+   assuming the tunnel server is also the IPv6 router emitting RAs. 
+   Well-known anycast addresses approach seems also simple in 
+   operation across the tunnel, but the deployment model using Well-
+   known anycast addresses in a tunneled environment is unclear or not 
+   well understood. 
+    
+5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP 
+    
+   This is similar to a typical IPv4 home user scenario, where DNS 
+   configuration parameters are obtained using DHCP.  Except that 
+   Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
+   DHCP server is stateful (maintains the state for clients). 
+    
+
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 18] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP 
+    
+   This is similar to Case B.  If a gateway provides IPv6 connectivity
+   by managing tunnels, then it is also supposed to provide access to 
+   an RDNSS.  Like this, the tunnel for IPv6 connectivity originates 
+   from the dual-stack gateway instead of the host. 
+    
+5.4.4 Case D: A gateway connected to an IPv6-only ISP 
+    
+   This is similar to Case B. 
+    
+6. Security Considerations 
+    
+   As security requirements depend solely on applications and are 
+   different application by application, there can be no generic 
+   requirement defined at higher IP or lower application layer of DNS.
+    
+   However, it should be noted that cryptographic security requires 
+   configured secret information that full autoconfiguration and 
+   cryptographic security are mutually exclusive.  People insisting on
+   secure full autoconfiguration will get false security, false 
+   autoconfiguration or both. 
+    
+   In some deployment scenario [19], where cryptographic security is 
+   required for applications, secret information for the cryptographic
+   security is preconfigured through which application specific 
+   configuration data, including those for DNS, can be securely 
+   configured.  It should be noted that if applications requiring 
+   cryptographic security depend on DNS, the applications also require
+   cryptographic security to DNS.  Therefore, the full auto-
+   configuration of DNS is not acceptable. 
+    
+   However, with full autoconfiguration, weaker but still reasonable 
+   security is being widely accepted and will continue to be 
+   acceptable.  That is, with full autoconfiguration, which means 
+   there is no cryptographic security for the autoconfiguration, it is
+   already assumed that local environment is secure enough that 
+   information from local autoconfiguration server has acceptable 
+   security even without cryptographic security.  Thus, communication 
+   between a local DNS client and a local DNS server has the 
+   acceptable security. 
+    
+   For security considerations of each approach, refer to the 
+   corresponding drafts [5]-[9]. 
+    
+7. Acknowledgements 
+    
+
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 19] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   This draft has greatly benefited from inputs by David Meyer, Rob 
+   Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, 
+   Christian Huitema, and Thomas Narten.  The authors appreciate their
+   contribution. 
+    
+8. Normative References 
+    
+   [1]  S. Bradner, "Intellectual Property Rights in IETF Technology",
+        RFC 3668, February 2004.  
+    
+   [2]  S. Bradner, "IETF Rights in Contributions", RFC 3667, February
+        2004. 
+    
+   [3]  T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for
+        IP Version 6 (IPv6)", RFC 2461, December 1998. 
+    
+   [4]  S. Thomson and T. Narten, "IPv6 Stateless Address 
+        Autoconfiguration", RFC 2462, December 1998. 
+    
+   [5]  R. Droms et al., "Dynamic Host Configuration Protocol for IPv6
+        (DHCPv6)", RFC 3315, July 2003. 
+    
+   [6]  R. Droms, "Stateless Dynamic Host Configuration Protocol 
+        (DHCP) Service for IPv6", RFC 3736, April 2004. 
+    
+   [7]  R. Droms et al., "DNS Configuration options for Dynamic Host 
+        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 
+        2003. 
+    
+9. Informative References 
+    
+   [8]  J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS 
+        Discovery based on Router Advertisement", draft-jeong-dnsop-
+        ipv6-dns-discovery-02.txt, July 2004. 
+    
+   [9]  M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta-
+        preconfigured-dns-01.txt, February 2004. 
+    
+   [10] S. Venaas and T. Chown, "Lifetime Option for DHCPv6", draft-
+        ietf-dhc-lifetime-00.txt, March 2004. 
+    
+   [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting 
+        Service", RFC 1546, November 1993. 
+    
+   [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6)
+        Addressing Architecture", RFC 3513, April 2003. 
+    
+
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 20] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6
+        into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis-
+        02.txt, April 2004. 
+    
+   [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft-
+        ietf-send-ndopt-05.txt, April 2004. 
+    
+   [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages", 
+        RFC 3118, June 2001. 
+    
+   [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", draft-
+        ietf-v6ops-ent-scenarios-01.txt, February 2004. 
+    
+   [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host 
+        Configuration Protocol (DHCP) version 6", RFC 3633, December 
+        2003. 
+    
+   [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP     
+        Standards", RFC 3314, September 2002. 
+    
+   [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks", 
+        RFC 3574, August 2003. 
+    
+   [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP     
+        Networks", draft-ietf-v6ops-3gpp-analysis-09.txt, March 2004. 
+    
+   [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); 
+        Service description; Stage 2 (Release 5)", December 2002. 
+    
+   [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 
+        specification; Core network protocols; Stage 3 (Release 5)",
+        June 2003. 
+    
+   [23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering  
+        Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless-
+        dhcpv6-renumbering-00.txt, March 2004. 
+    
+   [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition 
+        Scenarios", RFC 3750, April 2004. 
+    
+10. Authors' Addresses 
+    
+   Jaehoon Paul Jeong, Editor 
+   ETRI / PEC 
+   161 Gajeong-dong, Yuseong-gu 
+   Daejeon 305-350 
+   Korea 
+    
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 21] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   Phone: +82 42 860 1664 
+   Fax: +82 42 861 5404 
+   EMail: paul@etri.re.kr 
+    
+   Ralph Droms 
+   Cisco Systems 
+   1414 Massachusetts Ave. 
+   Boxboro, MA 01719 
+   USA 
+    
+   Phone: +1 978 936 1674 
+   EMail: rdroms@cisco.com 
+    
+   Robert M. Hinden 
+   Nokia 
+   313 Fairchild Drive 
+   Mountain View, CA 94043 
+   USA 
+    
+   Phone: +1 650 625 2004 
+   EMail: bob.hinden@nokia.com 
+    
+   Ted Lemon 
+   Nominum, Inc. 
+   950 Charter Street 
+   Redwood City, CA 94043 
+   USA 
+    
+   EMail: Ted.Lemon@nominum.com 
+    
+   Masataka Ohta 
+   Graduate School of Information Science and Engineering 
+   Tokyo Institute of Technology 
+   2-12-1, O-okayama, Meguro-ku 
+   Tokyo 152-8552 
+   Japan 
+    
+   Phone: +81 3 5734 3299 
+   Fax: +81 3 5734 3299 
+   EMail: mohta@necom830.hpcl.titech.ac.jp 
+    
+   Soohong Daniel Park 
+   Mobile Platform Laboratory, SAMSUNG Electronics 
+   416, Maetan-3dong, Paldal-gu, Suwon 
+   Gyeonggi-Do 
+   Korea 
+    
+   Phone: +82 31 200 4508 
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 22] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   EMail: soohong.park@samsung.com 
+    
+   Suresh Satapati 
+   Cisco Systems, Inc. 
+   San Jose, CA 95134 
+   USA 
+    
+   EMail: satapati@cisco.com 
+    
+   Juha Wiljakka 
+   Nokia 
+   Visiokatu 3 
+   FIN-33720 TAMPERE 
+   Finland 
+    
+   Phone: +358 7180 48372 
+   EMail: juha.wiljakka@nokia.com 
+    
+Intellectual Property Statement 
+    
+   The following intellectual property notice is copied from RFC3668,
+   Section 5. 
+    
+   The IETF takes no position regarding the validity or scope of any 
+   Intellectual Property Rights or other rights that might be claimed 
+   to pertain to the implementation or use of the technology described
+   in this document or the extent to which any license under such 
+   rights might or might not be available; nor does it represent that 
+   it has made any independent effort to identify any such rights.  
+   Information on the procedures with respect to rights in RFC 
+   documents can be found in BCP 78 and BCP 79. 
+    
+   Copies of IPR disclosures made to the IETF Secretariat and any 
+   assurances of licenses to be made available, or the result of an 
+   attempt made to obtain a general license or permission for the use 
+   of such proprietary rights by implementers or users of this 
+   specification can be obtained from the IETF on-line IPR repository 
+   at http://www.ietf.org/ipr. 
+    
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary 
+   rights that may cover technology that may be required to implement 
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org. 
+    
+Full Copyright Statement 
+    
+
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 23] 
+ 
+Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
+ 
+ 
+   The following copyright notice is copied from RFC3667, Section 5.4.
+   It describes the applicable copyright for this document. 
+    
+   Copyright (C) The Internet Society (2004).  This document is 
+   subject to the rights, licenses and restrictions contained in BCP 
+   78, and except as set forth therein, the authors retain all their 
+   rights. 
+    
+   This document and the information contained herein are provided on 
+   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 
+   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 
+   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 
+   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
+   PARTICULAR PURPOSE. 
+    
+Acknowledgement 
+    
+   Funding for the RFC Editor function is currently provided by the 
+   Internet Society. 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+ 
+Jeong, et al.             Expires - January 2005             [Page 24] 
+
+
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt
deleted file mode 100644
index 280c2f2d..00000000
--- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt
+++ /dev/null
@@ -1,1233 +0,0 @@
-
-
-DNS Operations WG                                              A. Durand
-Internet-Draft                                    SUN Microsystems, Inc.
-Expires: July 1, 2004                                           J. Ihren
-                                                              Autonomica
-                                                               P. Savola
-                                                               CSC/FUNET
-                                                                Jan 2004
-
-
-          Operational Considerations and Issues with IPv6 DNS
-                draft-ietf-dnsop-ipv6-dns-issues-04.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 1, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-   This memo presents operational considerations and issues with IPv6
-   Domain Name System (DNS), including a summary of special IPv6
-   addresses, documentation of known DNS implementation misbehaviour,
-   recommendations and considerations on how to perform DNS naming for
-   service provisioning and for DNS resolver IPv6 support,
-   considerations for DNS updates for both the forward and reverse
-   trees, and miscellaneous issues.  This memo is aimed to include a
-   summary of information about IPv6 DNS considerations for those who
-   have experience with IPv4 DNS.
-
-
-
-Durand, et al.            Expires July 1, 2004                  [Page 1]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . . .  3
-   1.2 Independence of DNS Transport and DNS Records  . . . . . . . .  3
-   1.3 Avoiding IPv4/IPv6 Name Space Fragmentation  . . . . . . . . .  4
-   2.  DNS Considerations about Special IPv6 Addresses  . . . . . . .  4
-   2.1 Limited-scope Addresses  . . . . . . . . . . . . . . . . . . .  4
-   2.2 Privacy (RFC3041) Address  . . . . . . . . . . . . . . . . . .  4
-   2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . . .  5
-   3.  Observed DNS Implementation Misbehaviour . . . . . . . . . . .  5
-   3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . . .  5
-   3.2 Misbehaviour of DNS Resolvers  . . . . . . . . . . . . . . . .  6
-   4.  Recommendations for Service Provisioning using DNS . . . . . .  6
-   4.1 Use of Service Names instead of Node Names . . . . . . . . . .  6
-   4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . . .  7
-   4.3 Adding the Records Only when Fully IPv6-enabled  . . . . . . .  7
-   4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . . .  8
-   4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments  . . . . . .  8
-   4.6 IPv6 Transport Guidelines for DNS Servers  . . . . . . . . . .  9
-   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . .  9
-   5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . . .  9
-   5.2 Recursive DNS Resolver Discovery . . . . . . . . . . . . . . . 11
-   5.3 IPv6 Transport Guidelines for Resolvers  . . . . . . . . . . . 11
-   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 11
-   6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 12
-   6.2 Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 13
-   7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . . . 13
-   7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 14
-   7.3 DDNS with Stateless Address Autoconfiguration  . . . . . . . . 14
-   7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . . . 14
-   7.5 DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . . . 15
-   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 15
-   8.1 NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . . . 15
-   8.2 Renumbering Procedures and Applications' Use of DNS  . . . . . 15
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
-   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
-       Normative References . . . . . . . . . . . . . . . . . . . . . 16
-       Informative References . . . . . . . . . . . . . . . . . . . . 16
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
-   A.  Site-local Addressing Considerations for DNS . . . . . . . . . 19
-       Intellectual Property and Copyright Statements . . . . . . . . 21
-
-
-
-
-
-
-
-
-Durand, et al.            Expires July 1, 2004                  [Page 2]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-1. Introduction
-
-   This memo presents operational considerations and issues with IPv6
-   DNS; it is meant to be an extensive summary and a list of pointers
-   for more information about IPv6 DNS considerations for those with
-   experience with IPv4 DNS.
-
-   The first section gives a brief overview of how IPv6 addresses and
-   names are represented in the DNS, how transport protocols and
-   resource records (don't) relate, and what IPv4/IPv6 name space
-   fragmentation means and how to avoid it; all of these are described
-   at more length in other documents.
-
-   The second section summarizes the special IPv6 address types and how
-   they relate to DNS.  The third section describes observed DNS
-   implementation misbehaviours which have a varying effect on the use
-   of IPv6 records with DNS.  The fourth section lists recommendations
-   and considerations for provisioning services with DNS.  The fifth
-   section in turn looks at recommendations and considerations about
-   providing IPv6 support in the resolvers.  The sixth and seventh
-   sections describe considerations with forward and reverse DNS
-   updates, respectively.  The eighth section introduces several
-   miscellaneous IPv6 issues relating to DNS for which no better place
-   has been found in this memo.  Appendix A looks briefly at the
-   requirements for site-local addressing.
-
-1.1 Representing IPv6 Addresses in DNS Records
-
-   In the forward zones, IPv6 addresses are represented using AAAA
-   records.  In the reverse zones, IPv6 address are represented using
-   PTR records in the nibble format under the ip6.arpa. -tree.  See [1]
-   for more about IPv6 DNS usage, and [2] or [4] for background
-   information.
-
-   In particular one should note that the use of A6 records, DNAME
-   records in the reverse tree, or Bitlabels in the reverse tree is not
-   recommended [2].
-
-1.2 Independence of DNS Transport and DNS Records
-
-   DNS has been designed to present a single, globally unique name space
-   [6].  This property should be maintained, as described here and in
-   Section 1.3.
-
-   In DNS, the IP version used to transport the queries and responses is
-   independent of the records being queried: AAAA records can be queried
-   over IPv4, and A records over IPv6. The DNS servers must not make any
-   assumptions about what data to return for Answer and Authority
-
-
-
-Durand, et al.            Expires July 1, 2004                  [Page 3]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   sections.
-
-   However, there is some debate whether the addresses in Additional
-   section could be selected or filtered using hints obtained from which
-   transport was being used; this has some obvious problems because in
-   many cases the transport protocol does not correlate with the
-   requests, and because a "bad" answer is in a way worse than no answer
-   at all (consider the case where the client is led to believe that a
-   name received in the additional record does not have any AAAA records
-   to begin with).
-
-   As stated in [1]:
-
-      The IP protocol version used for querying resource records is
-      independent of the protocol version of the resource records; e.g.,
-      IPv4 transport can be used to query IPv6 records and vice versa.
-
-
-1.3 Avoiding IPv4/IPv6 Name Space Fragmentation
-
-   To avoid the DNS name space from fragmenting into parts where some
-   parts of DNS are only visible using IPv4 (or IPv6) transport, the
-   recommendation is to always keep at least one authoritative server
-   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
-   See DNS IPv6 transport guidelines [3] for more information.
-
-2. DNS Considerations about Special IPv6 Addresses
-
-   There are a couple of IPv6 address types which are somewhat special;
-   these are considered here.
-
-2.1 Limited-scope Addresses
-
-   The IPv6 addressing architecture [5] includes two kinds of local-use
-   addresses: link-local (fe80::/10) and site-local (fec0::/10).  The
-   site-local addresses are being deprecated [7], and are only discussed
-   in Appendix A.
-
-   Link-local addresses should never be published in DNS, because they
-   have only local (to the connected link) significance [8].
-
-2.2 Privacy (RFC3041) Address
-
-   Privacy addresses (RFC3041 [9]) use a random number as the interface
-   identifier.  Publishing DNS records relating to such addresses would
-   defeat the purpose of the mechanism and is not recommended.  If
-   absolutely necessary, a mapping could be made to some
-   non-identifiable name, as described in [9].
-
-
-
-Durand, et al.            Expires July 1, 2004                  [Page 4]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-2.3 6to4 Addresses
-
-   6to4 [10] specifies an automatic tunneling mechanism which maps a
-   public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
-   Providing reverse DNS delegation path for such addresses is a
-   challenge.  Note that similar difficulties don't surface with the
-   other automatic tunneling mechanisms (in particular, providing
-   reverse DNS information for Teredo [11] hosts whose address includes
-   the UDP port of the NAT binding does not seem reasonable).
-
-   If the reverse DNS population would be desirable (see Section 7.1 for
-   applicability), there are a number of ways to tackle the delegation
-   path problem [12], some more applicable than the others.
-
-   The main proposal [13] has been to allocate 2.0.0.2.ip6.arpa. to RIRs
-   and let them do subdelegations in accordance to the delegations of
-   the respective IPv4 address space.  This has a major practical
-   drawback: those ISPs and IPv4 address space holders where 6to4 is
-   being used do not, in general, provide any IPv6 services -- as
-   otherwise, most people would not have to use 6to4 to begin with --
-   and it is improbable that the reverse delegation chain would be
-   completed either.  In most cases, creating such delegation chains
-   might just lead to latencies caused by lookups for (almost always)
-   non-existent DNS records.
-
-3. Observed DNS Implementation Misbehaviour
-
-   Several classes of misbehaviour in DNS servers, load-balancers and
-   resolvers have been observed.  Most of these are rather generic, not
-   only applicable to IPv6 -- but in some cases, the consequences of
-   this misbehaviour are extremely severe in IPv6 environments and
-   deserve to be mentioned.
-
-3.1 Misbehaviour of DNS Servers and Load-balancers
-
-   There are several classes of misbehaviour in certain DNS servers and
-   load-balancers which have been noticed and documented [14]: some
-   implementations silently drop queries for unimplemented DNS records
-   types, or provide wrong answers to such queries (instead of a proper
-   negative reply).  While typically these issues are not limited to
-   AAAA records, the problems are aggravated by the fact that AAAA
-   records are being queried instead of (mainly) A records.
-
-   The problems are serious because when looking up a DNS name, typical
-   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
-   to query the AAAA records of the name, and after receiving a
-   response, query the A records. This is done in a serial fashion -- if
-   the first query is never responded to (instead of properly returning
-
-
-
-Durand, et al.            Expires July 1, 2004                  [Page 5]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   a negative answer), significant timeouts will occur.
-
-   In consequence, this is an enormous problem for IPv6 deployments, and
-   in some cases, IPv6 support in the software has even been disabled
-   due to these problems.
-
-   The solution is to fix or retire those misbehaving implementations,
-   but that is likely not going to be effective.  There are some
-   possible ways to mitigate the problem, e.g. by performing the lookups
-   somewhat in parallel and reducing the timeout as long as at least one
-   answer has been received; but such methods remain to be investigated;
-   slightly more on this is included in Section 5.
-
-3.2 Misbehaviour of DNS Resolvers
-
-   Several classes of misbehaviour have also been noticed in DNS
-   resolvers [15].  However, these do not seem to directly impair IPv6
-   use, and are only referred to for completeness.
-
-4. Recommendations for Service Provisioning using DNS
-
-   When names are added in the DNS to facilitate a service, there are
-   several general guidelines to consider to be able to do it as
-   smoothly as possible.
-
-4.1 Use of Service Names instead of Node Names
-
-   When a node includes multiple services, one should keep them
-   logically separate in the DNS.  This can be done by the use of
-   service names instead of node names (or, "hostnames").
-
-   For example, assume a node named "pobox.example.com" provides both
-   SMTP and IMAP service.  Instead of configuring the MX records to
-   point at "pobox.example.com", and configuring the mail clients to
-   look up the mail via IMAP from "pobox.example.com", one should use
-   e.g. "smtp.example.com" for SMTP (for both message submission and
-   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
-   Note that in the specific case of SMTP relaying, the server itself
-   must typically also be configured to know all its names to ensure
-   loops do not occur. DNS can provide a layer of indirection between
-   service names and where the service actually is, and using which
-   addresses.
-
-   This is a good practice with IPv4 as well, because it provides more
-   flexibility and enables easier migration of services from one host to
-   another.  A specific reason why this is relevant for IPv6 is that the
-   different services may have a different level of IPv6 support -- that
-   is, one node providing multiple services might want to enable just
-
-
-
-Durand, et al.            Expires July 1, 2004                  [Page 6]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   one service to be IPv6-visible while keeping some others as
-   IPv4-only.  Using service names enables more flexibility with
-   different IP versions as well.
-
-4.2 Separate vs the Same Service Names for IPv4 and IPv6
-
-   The service naming can be achieved in basically two ways: when a
-   service is named "service.example.com" for IPv4, the IPv6-enabled
-   service could be either added to "service.example.com", or added
-   separately to a sub-domain, like, "service.ipv6.example.com".
-
-   Both methods have different characteristics.  Using a sub-domain
-   allows for easier service piloting, minimizing the disturbance to the
-   "regular" users of IPv4 service; however, the service would not be
-   used without explicitly asking for it (or, within a restricted
-   network, modifying the DNS search path) -- so it will not actually be
-   used that much.  Using the same service name is the "long-term"
-   solution, but may degrade performance for those clients whose IPv6
-   performance is lower than IPv4, or does not work as well (see the
-   next subsection for more).
-
-   In most cases, it makes sense to pilot or test a service using
-   separate service names, and move to the use of the same name when
-   confident enough that the service level will not degrade for the
-   users unaware of IPv6.
-
-4.3 Adding the Records Only when Fully IPv6-enabled
-
-   The recommendation is that AAAA records for a service should not be
-   added to the DNS until all of following are true:
-
-   1.  The address is assigned to the interface on the node.
-
-   2.  The address is configured on the interface.
-
-   3.  The interface is on a link which is connected to the IPv6
-       infrastructure.
-
-   In addition, if the AAAA record is added for the node, instead of
-   service as recommended, all the services of the node should be
-   IPv6-enabled prior to adding the resource record.
-
-   For example, if an IPv6 node is isolated from an IPv6 perspective
-   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
-   that it should not have an address in the DNS.
-
-   Consider the case of two dual-stack nodes, which both have IPv6
-   enabled, but the server does not have (global) IPv6 connectivity. As
-
-
-
-Durand, et al.            Expires July 1, 2004                  [Page 7]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   the client looks up the server's name, only A records are returned
-   (if the recommendations above are followed), and no IPv6
-   communication, which would have been unsuccessful, is even attempted.
-
-   The issues are not always so black-and-white.  Usually it's important
-   if the service offered using both protocols is of roughly equal
-   quality, using the appropriate metrics for the service (e.g.,
-   latency, throughput, low packet loss, general reliability, etc.) --
-   this is typically very important especially for interactive or
-   real-time services.  In many cases, the quality of IPv6 connectivity
-   is not yet equal to that of IPv4, at least globally -- this has to be
-   taken into consideration when enabling services [16].
-
-4.4 The Use of TTL for IPv4 and IPv6 RRs
-
-   The behaviour of DNS caching when different TTL values are used for
-   different records of the same name requires explicit discussion. For
-   example, let's consider a part of a zone:
-
-   example.com.        300    IN    MX     foo.example.com.
-   foo.example.com.    300    IN    A      192.0.2.1
-   foo.example.com.    100    IN    AAAA   2001:db8::1
-
-   Now, when a caching resolver asks for the MX record of example.com,
-   it gets both A and AAAA records of foo.example.com.  Then, after 100
-   seconds, the AAAA record is removed from the cache because its TTL
-   expired.  Now, subsequent queries only result in the cache returning
-   the A record; after 200 seconds the A record is purged as well.  So,
-   in this particular case, there is a window of 200 seconds when
-   incomplete information is returned from the cache.
-
-   Therefore, when the same name refers to both A and AAAA records,
-   these records should have the same TTL.  Otherwise, the caches may
-   return incomplete information about the queried names.  More issues
-   with caching and A/AAAA records is presented in the next section.
-
-4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments
-
-   In the previous section, we discussed the effect of impartial data
-   returned from the caches when the TTLs are not kept the same.  Now,
-   we present another problem highlighted in the mixed IPv4/IPv6
-   environments.
-
-   Consider the case where the query is so long or the number of the
-   additional ("glue") records is so high that the response must either
-   be truncated (leading to a retry with TCP) or some of the additional
-   data removed from the reply.  Further, resource record sets are never
-   "broken up", so if a name has 4 A records and 5 AAAA records, you can
-
-
-
-Durand, et al.            Expires July 1, 2004                  [Page 8]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   either return all 9, all 4 A records, all 5 AAAA records or nothing.
-
-   In the case of too much additional data, it might be tempting to not
-   return the AAAA records if the transport for DNS query was IPv4, or
-   not return the A records, if the transport was IPv6.  However, this
-   breaks the model of independence of DNS transport and resource
-   records, as noted in Section 1.2.
-
-   This temptation would have significant problems in multiple areas.
-   Remember that often the end-node, which will be using the records, is
-   not the same one as the node requesting them from the authorative DNS
-   server (or even a caching resolver).  So, whichever version the
-   requestor ("the middleman") uses makes no difference to the ultimate
-   user of the records.  This might result in e.g., inappropriately
-   returning A records to an IPv6-only node, going through a
-   translation, or opening up another IP-level session (e.g., a PDP
-   context [31]).
-
-   The problem of too much additional data seems to be an operational
-   one: the zone administrator entering too many records which will be
-   returned either truncated or impartial to the users.  A protocol fix
-   for this is using EDNS0 [32] to signal the capacity for larger UDP
-   packet sizes, pushing up the relevant threshold.  The operational fix
-   for this is having the DNS server implementations return a warning
-   when the administrators create the zones which would result in too
-   much additional data being returned.
-
-4.6 IPv6 Transport Guidelines for DNS Servers
-
-   As described in Section 1.3 and [3], there should continue to be at
-   least one authorative IPv4 DNS server for every zone, even if the
-   zone has only IPv6 records. (Note that obviously, having more servers
-   with robust connectivity would be preferable, but this is the minimum
-   recommendation; also see [17].)
-
-5. Recommendations for DNS Resolver IPv6 Support
-
-   When IPv6 is enabled on a node, there are several things to consider
-   to ensure that the process is as smooth as possible.
-
-5.1 DNS Lookups May Query IPv6 Records Prematurely
-
-   The system library that implements the getaddrinfo() function for
-   looking up names is a critical piece when considering the robustness
-   of enabling IPv6; it may come in basically three flavours:
-
-   1.  The system library does not know whether IPv6 has been enabled in
-       the kernel of the operating system: it may start looking up AAAA
-
-
-
-Durand, et al.            Expires July 1, 2004                  [Page 9]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-       records with getaddrinfo() and AF_UNSPEC hint when the system is
-       upgraded to a system library version which supports IPv6.
-
-   2.  The system library might start to perform IPv6 queries with
-       getaddrinfo() only when IPv6 has been enabled in the kernel.
-       However, this does not guarantee that there exists any useful
-       IPv6 connectivity (e.g., the node could be isolated from the
-       other IPv6 networks, only having link-local addresses).
-
-   3.  The system library might implement a toggle which would apply
-       some heuristics to the "IPv6-readiness" of the node before
-       starting to perform queries; for example, it could check whether
-       only link-local IPv6 address(es) exists, or if at least one
-       global IPv6 address exists.
-
-   First, let us consider generic implications of unnecessary queries
-   for AAAA records: when looking up all the records in the DNS, AAAA
-   records are typically tried first, and then A records.  These are
-   done in serial, and the A query is not performed until a response is
-   received to the AAAA query.  Considering the misbehaviour of DNS
-   servers and load-balancers, as described in Section 3.1, the look-up
-   delay for AAAA may incur additional unnecessary latency, and
-   introduce a component of unreliability.
-
-   One option here could be to do the queries partially in parallel; for
-   example, if the final response to the AAAA query is not received in
-   0.5 seconds, start performing the A query while waiting for the
-   result (immediate parallelism might be unoptimal without information
-   sharing between the look-up threads, as that would probably lead to
-   duplicate non-cached delegation chain lookups).
-
-   An additional concern is the address selection, which may, in some
-   circumstances, prefer AAAA records over A records, even when the node
-   does not have any IPv6 connectivity [18]. In some cases, the
-   implementation may attempt to connect or send a datagram on a
-   physical link [19], incurring very long protocol timeouts, instead of
-   quickly failing back to IPv4.
-
-   Now, we can consider the issues specific to each of the three
-   possibilities:
-
-   In the first case, the node performs a number of completely useless
-   DNS lookups as it will not be able to use the returned AAAA records
-   anyway. (The only exception is where the application desires to know
-   what's in the DNS, but not use the result for communication.)  One
-   should be able to disable these unnecessary queries, for both latency
-   and reliability reasons.  However, as IPv6 has not been enabled, the
-   connections to IPv6 addresses fail immediately, and if the
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 10]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   application is programmed properly, the application can fall
-   gracefully back to IPv4 [20].
-
-   The second case is similar to the first, except it happens to a
-   smaller set of nodes when IPv6 has been enabled but connectivity has
-   not been provided yet; similar considerations apply, with the
-   exception that IPv6 records, when returned, will be actually tried
-   first which may typically lead to long timeouts.
-
-   The third case is a bit more complex: optimizing away the DNS lookups
-   with only link-locals is probably safe (but may be desirable with
-   different lookup services which getaddrinfo() may support), as the
-   link-locals are typically automatically generated when IPv6 is
-   enabled, and do not indicate any form of IPv6 connectivity.   That
-   is, performing DNS lookups only when a non-link-local address has
-   been configured on any interface could be beneficial -- this would be
-   an indication that either the address has been configured either from
-   a router advertisement, DHCPv6, or manually.  Each would indicate at
-   least some form of IPv6 connectivity, even though there would not be
-   guarantees of it.
-
-   These issues should be analyzed at more depth, and the fixes found
-   consensus on, perhaps in a separate document.
-
-5.2 Recursive DNS Resolver Discovery
-
-   Recursive IPv6 DNS resolver discovery is a subject of active debate
-   at the moment: the main proposed mechanisms include the use of
-   well-known addresses [21], the use of Router Advertisements to convey
-   the information [22], and using DHCPv6 (or the stateless subset of it
-   [23]) for DNS resolver configuration. No consensus has been reached
-   yet.
-
-   Note that IPv6 DNS resolver discovery, while an important topic, is
-   not required for dual-stack nodes in dual-stack networks: IPv6 DNS
-   records can very well be queried over IPv4 as well.
-
-5.3 IPv6 Transport Guidelines for Resolvers
-
-   As described in Section 1.3 and [3], the recursive resolvers should
-   be IPv4-only or dual-stack to be able to reach any IPv4-only DNS
-   server.  Note that this requirement is also fulfilled by an IPv6-only
-   stub resolver pointing to a dual-stack recursive DNS resolver.
-
-6. Considerations about Forward DNS Updating
-
-   While the topic how to enable updating the forward DNS, i.e., the
-   mapping from names to the correct new addresses, is not specific to
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 11]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   IPv6, it bears thinking about especially due to adding Stateless
-   Address Autoconfiguration [24] to the mix.
-
-   Typically forward DNS updates are more manageable than doing them in
-   the reverse DNS, because the updater can, typically, be assumed to
-   "own" a certain DNS name -- and we can create a form of security
-   association with the DNS name and the node allowed to update it to
-   point to a new address.
-
-   A more complex form of DNS updates -- adding a whole new name to a
-   DNS zone, instead of updating an existing name -- is considered
-   out-of-scope: this is not an IPv6-specific problem, and one still
-   being explored.
-
-6.1 Manual or Custom DNS Updates
-
-   The DNS mappings can be maintained by hand, in a semi-automatic
-   fashion or by running non-standardized protocols.  These are not
-   considered at more length in this memo.
-
-6.2 Dynamic DNS
-
-   Dynamic DNS updates (DDNS) [25][26] is a standardized mechanism for
-   dynamically updating the DNS.  It works equally well with stateless
-   address autoconfiguration (SLAAC), DHCPv6 or manual address
-   configuration.  The only (minor) twist is that with SLAAC, the DNS
-   server cannot tie the authentication of the user to the IP address,
-   and stronger mechanisms must be used.  Actually, relying on IP
-   addresses for Dynamic DNS is rather insecure at best, so this is
-   probably not a significant problem (but requires that the
-   authorization keying will be explicitly configured).
-
-   Note that with DHCP, it is also possible that the DHCP server updates
-   the DNS, not the host.  The host might only indicate in the DHCP
-   exchange which hostname it would prefer, and the DHCP server would
-   make the appropriate updates. Nonetheless, while this makes setting
-   up a secure channel between the updater and the DNS server easier, it
-   does not help much with "content" security, i.e., whether the
-   hostname was acceptable -- if the DNS server does not include
-   policies, they must be included in the DHCP server (e.g., a regular
-   host should not be able to state that its name is "www.example.com").
-
-   The nodes must somehow be configured with the information about the
-   servers where they will attempt to update their addresses, sufficient
-   security material for authenticating themselves to the server, and
-   the hostname they will be updating.  Unless otherwise configured, the
-   first could be obtained by looking up the authorative name servers
-   for the hostname; the second must be configured explicitly unless one
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 12]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   chooses to trust the IP address -based authentication (not a good
-   idea); and lastly, the nodename is typically pre-configured somehow
-   on the node, e.g. at install time.
-
-   Care should be observed when updating the addresses not to use longer
-   TTLs for addresses than are preferred lifetimes for the
-   autoconfigured addresses, so that if the node is renumbered in a
-   managed fashion, the amount of stale DNS information is kept to the
-   minimum. Actually, the DNS TTL should be much shorter (e.g., a half
-   or a third) than the lifetime of an address; that way, the node can
-   start lowering the DNS TTL if it seems like the address has not be
-   renewed/refreshed in a while.  Some discussion on how to manage the
-   DNS TTL is included in [28].
-
-7. Considerations about Reverse DNS Updating
-
-   Forward DNS updating is rather straightforward; reverse DNS is
-   significantly trickier especially with certain mechanisms.  However,
-   first it makes sense to look at the applicability of reverse DNS in
-   the first place.
-
-7.1 Applicability of Reverse DNS
-
-   Today, some applications use reverse DNS to either look up some hints
-   about the topological information associated with an address (e.g.
-   resolving web server access logs), or as a weak form of a security
-   check, to get a feel whether the user's network administrator has
-   "authorized" the use of the address (on the premises that adding a
-   reverse record for an address would signal some form of
-   authorization).
-
-   One additional, maybe slightly more useful usage is ensuring the
-   reverse and forward DNS contents match and correspond to a configured
-   name or domain.  As a security check, it is typically accompanied by
-   other mechanisms, such as a user/password login; the main purpose of
-   the DNS check is to weed out the majority of unauthorized users, and
-   if someone managed to bypass the checks, he would still need to
-   authenticate "properly".
-
-   It is not clear whether it makes sense to require or recommend that
-   reverse DNS records be updated.  In many cases, it would just make
-   more sense to use proper mechanisms for security (or topological
-   information lookup) in the first place.  At minimum, the applications
-   which use it as a generic authorization (in the sense that a record
-   exists at all) should be modified as soon as possible to avoid such
-   lookups completely.
-
-   The applicability is discussed at more length in [29].
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 13]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-7.2 Manual or Custom DNS Updates
-
-   Reverse DNS can of course be updated using manual or custom methods.
-   These are not further described here, except for one special case.
-
-   One way to deploy reverse DNS would be to use wildcard records, for
-   example, by configuring one name for a subnet (/64) or a site (/48).
-   Naturally, such a name could not be verified from the forward DNS,
-   but would at least provide some form of "topological information" or
-   "weak authorization" if that is really considered to be useful.  Note
-   that this is not actually updating the DNS as such, as the whole
-   point is to avoid DNS updates completely by manually configuring a
-   generic name.
-
-7.3 DDNS with Stateless Address Autoconfiguration
-
-   Dynamic DNS with SLAAC is a bit complicated, but manageable with a
-   rather low form of security with some implementation.
-
-   Every node on a link must then be allowed to insert its own reverse
-   DNS record in the reverse zone.  However, in the typical case, there
-   can be no stronger form of authentication between the nodes and the
-   server than the source IP address (the user may roam to other
-   administrative domains as well, requiring updates to foreign DNS
-   servers), which might make attacks more lucrative.
-
-   Moreover, the reverse zones must be cleaned up by some janitorial
-   process: the node does not typically know a priori that it will be
-   disconnected, and cannot send a DNS update using the correct source
-   address to remove a record.
-
-   To insert or update the record, the node must discover the DNS server
-   to send the update to somehow, similar to as discussed in Section
-   6.2. One way to automate this is looking up the DNS server
-   authoritative for the IP address being updated, but the security
-   material (unless the IP address -based authorization is trusted) must
-   also be established by some other means.
-
-7.4 DDNS with DHCP
-
-   With DHCP, the reverse DNS name is typically already inserted to the
-   DNS that reflects to the name (e.g., "dhcp-67.example.com").  This is
-   pre-configured, and requires no updating.
-
-   If a more explicit control is required, similar considerations as
-   with SLAAC apply, except for the fact that typically one must update
-   a reverse DNS record instead of inserting one -- due to a denser
-   address assignment policy -- and updating a record seems like a
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 14]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   slightly more difficult thing to secure.
-
-   Note that when using DHCP, either the host or the DHCP server could
-   perform the DNS updates; see the implications in Section 6.2.
-
-7.5 DDNS with Dynamic Prefix Delegation
-
-   In cases where more than one address is being used and updated, one
-   should consider where the updated server resides.  That is, whether
-   the prefixes have been delegated to a node in the local site, or
-   whether they reside elsewhere, e.g., at the ISP.  The reverse DNS
-   updates are typically easier to manage if they can be done within a
-   single administrative entity -- and therefore, if a reverse DNS
-   delegation has been made, it may be easier to enable reverse DNS at
-   the site, e.g. by a wildcard record, or by some DNS update mechanism.
-
-8. Miscellaneous DNS Considerations
-
-   This section describes miscellaneous considerations about DNS which
-   seem related to IPv6, for which no better place has been found in
-   this document.
-
-8.1 NAT-PT with DNS-ALG
-
-   NAT-PT [27] DNS-ALG is a critical component (unless something
-   replacing that functionality is specified) which mangles A records to
-   look like AAAA records to the IPv6-only nodes. Numerous problems have
-   been identified with DNS-ALG [30].
-
-8.2 Renumbering Procedures and Applications' Use of DNS
-
-   One of the most difficult problems of systematic IP address
-   renumbering procedures [28] is that an application which looks up a
-   DNS name disregards information such as TTL, and uses the result
-   obtained from DNS as long as it happens to be stored in the memory of
-   the application.  For applications which run for a long time, this
-   could be days, weeks or even months; some applications may be clever
-   enough to organize the data structures and functions in such a manner
-   that look-ups get refreshed now and then.
-
-   While the issue appears to have a clear solution, "fix the
-   applications", practically this is not reasonable immediate advice;
-   the TTL information is not typically available in the APIs and
-   libraries (so, the advice becomes "fix the applications, APIs and
-   libraries"), and a lot more analysis is needed on how to practically
-   go about to achieve the ultimate goal of avoiding using the names
-   longer than expected.
-
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 15]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-9. Acknowledgements
-
-   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
-   provisioning were moved here from [33] by Erik Nordmark and Bob
-   Gilligan.  Havard Eidnes and Michael Patton provided useful feedback
-   and improvements.  Scott Rose, Rob Austein, Masataka Ohta, and Mark
-   Andrews helped in clarifying the issues regarding additional data and
-   the use of TTL.
-
-10. Security Considerations
-
-   This document reviews the operational procedures for IPv6 DNS
-   operations and does not have security considerations in itself.
-
-   However, it is worth noting that in particular with Dynamic DNS
-   Updates, security models based on the source address validation are
-   very weak and cannot be recommended.  On the other hand, it should be
-   noted that setting up an authorization mechanism (e.g., a shared
-   secret, or public-private keys) between a node and the DNS server has
-   to be done manually, and may require quite a bit of time and
-   expertise.
-
-   To re-emphasize which was already stated, reverse DNS checks provide
-   very weak security at best, and the only (questionable)
-   security-related use for them may be in conjunction with other
-   mechanisms when authenticating a user.
-
-Normative References
-
-   [1]  Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
-        Extensions to Support IP Version 6", RFC 3596, October 2003.
-
-   [2]  Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain,
-        "Representing Internet Protocol version 6 (IPv6) Addresses in
-        the Domain Name System (DNS)", RFC 3363, August 2002.
-
-   [3]  Durand, A. and J. Ihren, "DNS IPv6 transport operational
-        guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-01 (work
-        in progress), October 2003.
-
-Informative References
-
-   [4]   Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August
-         2001.
-
-   [5]   Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-         Addressing Architecture", RFC 3513, April 2003.
-
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 16]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   [6]   Internet Architecture Board, "IAB Technical Comment on the
-         Unique DNS Root", RFC 2826, May 2000.
-
-   [7]   Huitema, C. and B. Carpenter, "Deprecating Site Local
-         Addresses", draft-ietf-ipv6-deprecate-site-local-02 (work in
-         progress), November 2003.
-
-   [8]   Hazel, P., "IP Addresses that should never appear in the public
-         DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in
-         progress), February 2002.
-
-   [9]   Narten, T. and R. Draves, "Privacy Extensions for Stateless
-         Address Autoconfiguration in IPv6", RFC 3041, January 2001.
-
-   [10]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
-         IPv4 Clouds", RFC 3056, February 2001.
-
-   [11]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
-         draft-huitema-v6ops-teredo-00 (work in progress), June 2003.
-
-   [12]  Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work in
-         progress), October 2002.
-
-   [13]  Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa",
-         draft-ymbk-6to4-arpa-delegation-00 (work in progress), February
-         2003.
-
-   [14]  Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS
-         Queries for IPv6 Addresses",
-         draft-morishita-dnsop-misbehavior-against-aaaa-00 (work in
-         progress), June 2003.
-
-   [15]  Larson, M. and P. Barber, "Observed DNS Resolution
-         Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in
-         progress), June 2003.
-
-   [16]  Savola, P., "Moving from 6bone to IPv6 Internet",
-         draft-savola-v6ops-6bone-mess-01 (work in progress), November
-         2002.
-
-   [17]  Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and
-         Operation of Secondary DNS Servers", BCP 16, RFC 2182, July
-         1997.
-
-   [18]  Roy, S., "Dual Stack IPv6 on by Default",
-         draft-ietf-v6ops-v6onbydefault-00 (work in progress), October
-         2003.
-
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 17]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   [19]  Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered
-         Harmful", draft-ietf-v6ops-onlinkassumption-00 (work in
-         progress), October 2003.
-
-   [20]  Shin, M., "Application Aspects of IPv6 Transition",
-         draft-ietf-v6ops-application-transition-00 (work in progress),
-         December 2003.
-
-   [21]  Ohta, M., "Preconfigured DNS Server Addresses",
-         draft-ohta-preconfigured-dns-00 (work in progress), July 2003.
-
-   [22]  Jeong, J., "IPv6 DNS Discovery based on Router Advertisement",
-         draft-jeong-dnsop-ipv6-dns-discovery-00 (work in progress),
-         July 2003.
-
-   [23]  Droms, R., "Stateless DHCP Service for IPv6",
-         draft-ietf-dhc-dhcpv6-stateless-04 (work in progress), January
-         2004.
-
-   [24]  Thomson, S. and T. Narten, "IPv6 Stateless Address
-         Autoconfiguration", RFC 2462, December 1998.
-
-   [25]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-         April 1997.
-
-   [26]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-   [27]  Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
-         Protocol Translation (NAT-PT)", RFC 2766, February 2000.
-
-   [28]  Baker, F., "Procedures for Renumbering an IPv6 Network without
-         a Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in
-         progress), October 2003.
-
-   [29]  Senie, D., "Requiring DNS IN-ADDR Mapping",
-         draft-ietf-dnsop-inaddr-required-03 (work in progress), March
-         2002.
-
-   [30]  Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
-         draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress),
-         February 2003.
-
-   [31]  Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks",
-         draft-ietf-v6ops-3gpp-analysis-07 (work in progress), October
-         2003.
-
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 18]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   [32]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
-         August 1999.
-
-   [33]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
-         IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-01 (work in
-         progress), October 2003.
-
-
-Authors' Addresses
-
-   Alain Durand
-   SUN Microsystems, Inc.
-   17 Network circle UMPL17-202
-   Menlo Park, CA  94025
-   USA
-
-   EMail: Alain.Durand@sun.com
-
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm
-   Sweden
-
-   EMail: johani@autonomica.se
-
-
-   Pekka Savola
-   CSC/FUNET
-
-   Espoo
-   Finland
-
-   EMail: psavola@funet.fi
-
-Appendix A. Site-local Addressing Considerations for DNS
-
-   As site-local addressing is being deprecated, and it is not yet clear
-   whether an addressing-based replacement (and which kind) is devised,
-   the considerations for site-local addressing are discussed briefly
-   here.
-
-   The interactions with DNS come in two flavors: forward and reverse
-   DNS.
-
-   To actually use site-local addresses within a site, this implies the
-   deployment of a "split-faced" or a fragmented DNS name space, for the
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 19]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   zones internal to the site, and the outsiders' view to it.  The
-   procedures to achieve this are not elaborated here.  The implication
-   is that site-local addresses must not be published in the public DNS.
-
-   To faciliate reverse DNS (if desired) with site-local addresses, the
-   stub resolvers must look for DNS information from the local DNS
-   servers, not e.g. starting from the root servers, so that the
-   site-local information may be provided locally.  Note that the
-   experience private addresses in IPv4 has shown that the root servers
-   get loaded for requests for private address lookups in any.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 20]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 21]
-
-Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.            Expires July 1, 2004                 [Page 22]
-
-
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
new file mode 100644
index 00000000..b14f711d
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
@@ -0,0 +1,1969 @@
+
+
+DNS Operations WG                                              A. Durand
+Internet-Draft                                    SUN Microsystems, Inc.
+Expires: February 7, 2005                                       J. Ihren
+                                                              Autonomica
+                                                               P. Savola
+                                                               CSC/FUNET
+                                                          August 9, 2004
+
+
+
+          Operational Considerations and Issues with IPv6 DNS
+                draft-ietf-dnsop-ipv6-dns-issues-09.txt
+
+
+Status of this Memo
+
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+   This Internet-Draft will expire on February 7, 2005.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   This memo presents operational considerations and issues with IPv6
+   Domain Name System (DNS), including a summary of special IPv6
+   addresses, documentation of known DNS implementation misbehaviour,
+   recommendations and considerations on how to perform DNS naming for
+
+
+
+
+Durand, et al.          Expires February 7, 2005                [Page 1]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   service provisioning and for DNS resolver IPv6 support,
+   considerations for DNS updates for both the forward and reverse
+   trees, and miscellaneous issues.  This memo is aimed to include a
+   summary of information about IPv6 DNS considerations for those who
+   have experience with IPv4 DNS.
+
+
+Table of Contents
+
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1   Representing IPv6 Addresses in DNS Records . . . . . . . .  4
+     1.2   Independence of DNS Transport and DNS Records  . . . . . .  4
+     1.3   Avoiding IPv4/IPv6 Name Space Fragmentation  . . . . . . .  5
+     1.4   Query Type '*' and A/AAAA Records  . . . . . . . . . . . .  5
+   2.  DNS Considerations about Special IPv6 Addresses  . . . . . . .  5
+     2.1   Limited-scope Addresses  . . . . . . . . . . . . . . . . .  6
+     2.2   Temporary Addresses  . . . . . . . . . . . . . . . . . . .  6
+     2.3   6to4 Addresses . . . . . . . . . . . . . . . . . . . . . .  6
+     2.4   Other Transition Mechanisms  . . . . . . . . . . . . . . .  6
+   3.  Observed DNS Implementation Misbehaviour . . . . . . . . . . .  7
+     3.1   Misbehaviour of DNS Servers and Load-balancers . . . . . .  7
+     3.2   Misbehaviour of DNS Resolvers  . . . . . . . . . . . . . .  7
+   4.  Recommendations for Service Provisioning using DNS . . . . . .  8
+     4.1   Use of Service Names instead of Node Names . . . . . . . .  8
+     4.2   Separate vs the Same Service Names for IPv4 and IPv6 . . .  8
+     4.3   Adding the Records Only when Fully IPv6-enabled  . . . . .  9
+     4.4   Behaviour of Additional Data in IPv4/IPv6 Environments . . 10
+       4.4.1   Description of Additional Data Scenarios . . . . . . . 10
+       4.4.2   Discussion of the Problems . . . . . . . . . . . . . . 11
+     4.5   The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12
+     4.6   IPv6 Transport Guidelines for DNS Servers  . . . . . . . . 13
+   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . . 13
+     5.1   DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14
+     5.2   Obtaining a List of DNS Recursive Resolvers  . . . . . . . 15
+     5.3   IPv6 Transport Guidelines for Resolvers  . . . . . . . . . 16
+   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 16
+     6.1   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
+     6.2   Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . 17
+   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 18
+     7.1   Applicability of Reverse DNS . . . . . . . . . . . . . . . 18
+     7.2   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19
+     7.3   DDNS with Stateless Address Autoconfiguration  . . . . . . 19
+     7.4   DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20
+     7.5   DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . 21
+   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22
+     8.1   NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . 22
+     8.2   Renumbering Procedures and Applications' Use of DNS  . . . 22
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
+   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 22
+
+
+
+
+Durand, et al.          Expires February 7, 2005                [Page 2]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 23
+   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 23
+   11.2  Informative References . . . . . . . . . . . . . . . . . . . 25
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
+   A.  Site-local Addressing Considerations for DNS . . . . . . . . . 28
+   B.  Issues about Additional Data or TTL  . . . . . . . . . . . . . 28
+       Intellectual Property and Copyright Statements . . . . . . . . 30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al.          Expires February 7, 2005                [Page 3]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+1.  Introduction
+
+
+   This memo presents operational considerations and issues with IPv6
+   DNS; it is meant to be an extensive summary and a list of pointers
+   for more information about IPv6 DNS considerations for those with
+   experience with IPv4 DNS.
+
+
+   The purpose of this document is to give information about various
+   issues and considerations related to DNS operations with IPv6; it is
+   not meant to be a normative specification or standard for IPv6 DNS.
+
+
+   The first section gives a brief overview of how IPv6 addresses and
+   names are represented in the DNS, how transport protocols and
+   resource records (don't) relate, and what IPv4/IPv6 name space
+   fragmentation means and how to avoid it; all of these are described
+   at more length in other documents.
+
+
+   The second section summarizes the special IPv6 address types and how
+   they relate to DNS.  The third section describes observed DNS
+   implementation misbehaviours which have a varying effect on the use
+   of IPv6 records with DNS.  The fourth section lists recommendations
+   and considerations for provisioning services with DNS.  The fifth
+   section in turn looks at recommendations and considerations about
+   providing IPv6 support in the resolvers.  The sixth and seventh
+   sections describe considerations with forward and reverse DNS
+   updates, respectively.  The eighth section introduces several
+   miscellaneous IPv6 issues relating to DNS for which no better place
+   has been found in this memo.  Appendix A looks briefly at the
+   requirements for site-local addressing.
+
+
+1.1  Representing IPv6 Addresses in DNS Records
+
+
+   In the forward zones, IPv6 addresses are represented using AAAA
+   records.  In the reverse zones, IPv6 address are represented using
+   PTR records in the nibble format under the ip6.arpa.  tree.  See
+   [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
+   for background information.
+
+
+   In particular one should note that the use of A6 records in the
+   forward tree or Bitlabels in the reverse tree is not recommended
+   [RFC3363].  Using DNAME records is not recommended in the reverse
+   tree in conjunction with A6 records; the document did not mean to
+   take a stance on any other use of DNAME records [RFC3364].
+
+
+1.2  Independence of DNS Transport and DNS Records
+
+
+   DNS has been designed to present a single, globally unique name space
+   [RFC2826].  This property should be maintained, as described here and
+
+
+
+
+Durand, et al.          Expires February 7, 2005                [Page 4]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   in Section 1.3.
+
+
+   The IP version used to transport the DNS queries and responses is
+   independent of the records being queried: AAAA records can be queried
+   over IPv4, and A records over IPv6.  The DNS servers must not make
+   any assumptions about what data to return for Answer and Authority
+   sections based on the underlying transport used in a query.
+
+
+   However, there is some debate whether the addresses in Additional
+   section could be selected or filtered using hints obtained from which
+   transport was being used; this has some obvious problems because in
+   many cases the transport protocol does not correlate with the
+   requests, and because a "bad" answer is in a way worse than no answer
+   at all (consider the case where the client is led to believe that a
+   name received in the additional record does not have any AAAA records
+   at all).
+
+
+   As stated in [RFC3596]:
+
+
+      The IP protocol version used for querying resource records is
+      independent of the protocol version of the resource records; e.g.,
+      IPv4 transport can be used to query IPv6 records and vice versa.
+
+
+
+1.3  Avoiding IPv4/IPv6 Name Space Fragmentation
+
+
+   To avoid the DNS name space from fragmenting into parts where some
+   parts of DNS are only visible using IPv4 (or IPv6) transport, the
+   recommendation is to always keep at least one authoritative server
+   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
+   See DNS IPv6 transport guidelines
+   [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information.
+
+
+1.4  Query Type '*' and A/AAAA Records
+
+
+   QTYPE=* is typically only used for debugging or management purposes;
+   it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
+   any available RRsets, not *all* the RRsets, because the caches do not
+   necessarily have all the RRsets and have no way of guaranteeing that
+   they have all the RRsets.  Therefore, to get both A and AAAA records
+   reliably, two separate queries must be made.
+
+
+2.  DNS Considerations about Special IPv6 Addresses
+
+
+   There are a couple of IPv6 address types which are somewhat special;
+   these are considered here.
+
+
+
+
+
+
+Durand, et al.          Expires February 7, 2005                [Page 5]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+2.1  Limited-scope Addresses
+
+
+   The IPv6 addressing architecture [RFC3513] includes two kinds of
+   local-use addresses: link-local (fe80::/10) and site-local (fec0::/
+   10).  The site-local addresses have been deprecated
+   [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in
+   Appendix A.
+
+
+   Link-local addresses should never be published in DNS (whether in
+   forward or reverse tree), because they have only local (to the
+   connected link) significance
+   [I-D.ietf-dnsop-dontpublish-unreachable].
+
+
+2.2  Temporary Addresses
+
+
+   Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
+   "privacy addresses") use a random number as the interface identifier.
+   Publishing (useful) DNS records relating to such addresses would
+   defeat the purpose of the mechanism and is not recommended.  However,
+   it would still be possible to return a non-identifiable name (e.g.,
+   the IPv6 address in hexadecimal format), as described in [RFC3041].
+
+
+2.3  6to4 Addresses
+
+
+   6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
+   a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
+
+
+   If the reverse DNS population would be desirable (see Section 7.1 for
+   applicability), there are a number of possible ways to do so
+   [I-D.moore-6to4-dns], some more applicable than the others.
+
+
+   The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
+   autonomous reverse-delegation system that anyone being capable of
+   communicating using a specific 6to4 address would be able to set up a
+   reverse delegation to the corresponding 6to4 prefix.  This could be
+   deployed by e.g., Regional Internet Registries (RIRs).  This is a
+   practical solution, but may have some scalability concerns.
+
+
+2.4  Other Transition Mechanisms
+
+
+   6to4, above, is mentioned as a case of an IPv6 transition mechanism
+   requiring special considerations.  In general, mechanisms which
+   include a special prefix may need a custom solution; otherwise, for
+   example when IPv4 address is embedded as the suffix or not embedded
+   at all, special solutions are likely not needed.  This is why only
+   6to4 and Teredo [I-D.huitema-v6ops-teredo] are described.
+
+
+   Note that it does not seem feasible to provide reverse DNS with
+
+
+
+
+Durand, et al.          Expires February 7, 2005                [Page 6]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   another automatic tunneling mechanism, Teredo; this is because the
+   IPv6 address is based on the IPv4 address and UDP port of the current
+   NAT mapping which is likely to be relatively short-lived.
+
+
+3.  Observed DNS Implementation Misbehaviour
+
+
+   Several classes of misbehaviour in DNS servers, load-balancers and
+   resolvers have been observed.  Most of these are rather generic, not
+   only applicable to IPv6 -- but in some cases, the consequences of
+   this misbehaviour are extremely severe in IPv6 environments and
+   deserve to be mentioned.
+
+
+3.1  Misbehaviour of DNS Servers and Load-balancers
+
+
+   There are several classes of misbehaviour in certain DNS servers and
+   load-balancers which have been noticed and documented
+   [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations
+   silently drop queries for unimplemented DNS records types, or provide
+   wrong answers to such queries (instead of a proper negative reply).
+   While typically these issues are not limited to AAAA records, the
+   problems are aggravated by the fact that AAAA records are being
+   queried instead of (mainly) A records.
+
+
+   The problems are serious because when looking up a DNS name, typical
+   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
+   to query the AAAA records of the name, and after receiving a
+   response, query the A records.  This is done in a serial fashion --
+   if the first query is never responded to (instead of properly
+   returning a negative answer), significant timeouts will occur.
+
+
+   In consequence, this is an enormous problem for IPv6 deployments, and
+   in some cases, IPv6 support in the software has even been disabled
+   due to these problems.
+
+
+   The solution is to fix or retire those misbehaving implementations,
+   but that is likely not going to be effective.  There are some
+   possible ways to mitigate the problem, e.g., by performing the
+   lookups somewhat in parallel and reducing the timeout as long as at
+   least one answer has been received; but such methods remain to be
+   investigated; slightly more on this is included in Section 5.
+
+
+3.2  Misbehaviour of DNS Resolvers
+
+
+   Several classes of misbehaviour have also been noticed in DNS
+   resolvers [I-D.ietf-dnsop-bad-dns-res].  However, these do not seem
+   to directly impair IPv6 use, and are only referred to for
+   completeness.
+
+
+
+
+
+Durand, et al.          Expires February 7, 2005                [Page 7]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+4.  Recommendations for Service Provisioning using DNS
+
+
+   When names are added in the DNS to facilitate a service, there are
+   several general guidelines to consider to be able to do it as
+   smoothly as possible.
+
+
+4.1  Use of Service Names instead of Node Names
+
+
+   When a node provides multiple services which should not be
+   fate-sharing, or might support different IP versions, one should keep
+   them logically separate in the DNS.  Using SRV records [RFC2782]
+   would avoid these problems.  Unfortunately, those are not
+   sufficiently widely used to be applicable in most cases.  Hence an
+   operation technique is to use service names instead of node names
+   (or, "hostnames").  This operational technique is not specific to
+   IPv6, but required to understand the considerations described in
+   Section 4.2 and Section 4.3.
+
+
+   For example, assume a node named "pobox.example.com" provides both
+   SMTP and IMAP service.  Instead of configuring the MX records to
+   point at "pobox.example.com", and configuring the mail clients to
+   look up the mail via IMAP from "pobox.example.com", one should use
+   e.g., "smtp.example.com" for SMTP (for both message submission and
+   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
+   Note that in the specific case of SMTP relaying, the server itself
+   must typically also be configured to know all its names to ensure
+   loops do not occur.  DNS can provide a layer of indirection between
+   service names and where the service actually is, and using which
+   addresses.  (Obviously, when wanting to reach a specific node, one
+   should use the hostname rather than a service name.)
+
+
+   This is a good practice with IPv4 as well, because it provides more
+   flexibility and enables easier migration of services from one host to
+   another.  A specific reason why this is relevant for IPv6 is that the
+   different services may have a different level of IPv6 support -- that
+   is, one node providing multiple services might want to enable just
+   one service to be IPv6-visible while keeping some others as
+   IPv4-only, improving flexibility.
+
+
+4.2  Separate vs the Same Service Names for IPv4 and IPv6
+
+
+   The service naming can be achieved in basically two ways: when a
+   service is named "service.example.com" for IPv4, the IPv6-enabled
+   service could be either added to "service.example.com", or added
+   separately under a different name, e.g., in a sub-domain, like,
+   "service.ipv6.example.com".
+
+
+   These two methods have different characteristics.  Using a different
+
+
+
+
+Durand, et al.          Expires February 7, 2005                [Page 8]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   name allows for easier service piloting, minimizing the disturbance
+   to the "regular" users of IPv4 service; however, the service would
+   not be used transparently, without the user/application explicitly
+   finding it and asking for it -- which would be a disadvantage in most
+   cases.  When the different name is under a sub-domain, if the
+   services are deployed within a restricted network (e.g., inside an
+   enterprise), it's possible to prefer them transparently, at least to
+   a degree, by modifying the DNS search path; however, this is a
+   suboptimal solution.  Using the same service name is the "long-term"
+   solution, but may degrade performance for those clients whose IPv6
+   performance is lower than IPv4, or does not work as well (see Section
+   4.3 for more).
+
+
+   In most cases, it makes sense to pilot or test a service using
+   separate service names, and move to the use of the same name when
+   confident enough that the service level will not degrade for the
+   users unaware of IPv6.
+
+
+4.3  Adding the Records Only when Fully IPv6-enabled
+
+
+   The recommendation is that AAAA records for a service should not be
+   added to the DNS until all of following are true:
+
+
+   1.  The address is assigned to the interface on the node.
+
+
+   2.  The address is configured on the interface.
+
+
+   3.  The interface is on a link which is connected to the IPv6
+       infrastructure.
+
+
+   In addition, if the AAAA record is added for the node, instead of
+   service as recommended, all the services of the node should be
+   IPv6-enabled prior to adding the resource record.
+
+
+   For example, if an IPv6 node is isolated from an IPv6 perspective
+   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
+   that it should not have an address in the DNS.
+
+
+   Consider the case of two dual-stack nodes, which both have IPv6
+   enabled, but the server does not have (global) IPv6 connectivity.  As
+   the client looks up the server's name, only A records are returned
+   (if the recommendations above are followed), and no IPv6
+   communication, which would have been unsuccessful, is even attempted.
+
+
+   The issues are not always so black-and-white.  Usually it's important
+   if the service offered using both protocols is of roughly equal
+   quality, using the appropriate metrics for the service (e.g.,
+   latency, throughput, low packet loss, general reliability, etc.) --
+
+
+
+
+Durand, et al.          Expires February 7, 2005                [Page 9]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   this is typically very important especially for interactive or
+   real-time services.  In many cases, the quality of IPv6 connectivity
+   may not yet be equal to that of IPv4, at least globally -- this has
+   to be taken into consideration when enabling services
+   [I-D.savola-v6ops-6bone-mess].
+
+
+4.4  Behaviour of Additional Data in IPv4/IPv6 Environments
+
+
+4.4.1  Description of Additional Data Scenarios
+
+
+   Consider the case where the query name is so long, the number of the
+   additional records is so high, or for other reasons that the entire
+   response would not fit in a single UDP packet.  In some cases, the
+   responder truncates the response with the TC bit being set (leading
+   to a retry with TCP), in order for the querier to get the entire
+   response later.
+
+
+   There are two kinds of additional data:
+
+
+   1.  glue, i.e., "critical" additional data; this must be included in
+       all scenarios, with all the RRsets as possible, and
+
+
+   2.  "courtesy" additional data; this could be sent in full, with only
+       a few RRsets, or with no RRsets, and can be fetched separately as
+       well, but at the cost of additional queries.  This data must
+       never cause setting of the TC bit.
+
+
+   The responding server can algorithmically determine which type the
+   additional data is by checking whether it's at or below a zone cut.
+
+
+   Meanwhile, resource record sets (RRsets) are never "broken up", so if
+   a name has 4 A records and 5 AAAA records, you can either return all
+   9, all 4 A records, all 5 AAAA records or nothing.  In particular,
+   notice that for the "critical" additional data getting all the RRsets
+   can be critical.
+
+
+   An example of the "courtesy" additional data is A/AAAA records in
+   conjunction of MX records as shown in Section 4.5; an example of the
+   "critical" additional data is shown below (where getting both the A
+   and AAAA RRsets is critical):
+
+
+      child.example.com.    IN   NS ns.child.example.com.
+      ns.child.example.com. IN    A 192.0.2.1
+      ns.child.example.com. IN AAAA 2001:db8::1
+
+
+   When there is too much courtesy additional data, some or all of it
+   need to be removed [RFC2181]; if some is left in the response, the
+   issue is which data should be retained.  When there is too much
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 10]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   critical additional data, TC bit will have to be set, and some or all
+   of it need to be removed; if some is left in the response, the issue
+   is which data should be retained.
+
+
+   If the implementation decides to keep as much data as possible, it
+   might be tempting to use the transport of the DNS query as a hint in
+   either of these cases: return the AAAA records if the query was done
+   over IPv6, or return the A records if the query was done over IPv4.
+   However, this breaks the model of independence of DNS transport and
+   resource records, as noted in Section 1.2.
+
+
+   It is worth remembering that often the host using the records is
+   different from the node requesting them from the authoritative DNS
+   server (or even a caching resolver).  So, whichever version the
+   requestor (e.g., a recursive server in the middle) uses makes no
+   difference to the ultimate user of the records, whose transport
+   capabilities might differ from those of the requestor.  This might
+   result in e.g., inappropriately returning A records to an IPv6-only
+   node, going through a translation, or opening up another IP-level
+   session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
+   Therefore, at least in many scenarios, it would be very useful if the
+   information returned would be consistent and complete -- or if that
+   is not feasible, return no misleading information but rather leave it
+   to the client to query again.
+
+
+4.4.2  Discussion of the Problems
+
+
+   As noted above, the temptation for omitting only some of the
+   additional data based on the transport of the query could be
+   problematic.  In particular, there appears to be little justification
+   for doing so in the case of "courtesy" data.
+
+
+   However, with critical additional data, the alternatives are either
+   returning nothing (and requiring a retry with TCP) or returning
+   something (possibly obviating the need for a retry with TCP).  If the
+   process for selecting "something" from the critical data would
+   otherwise be practically "flipping the coin" between A and AAAA
+   records, it could be argued that if one looked at the transport of
+   the query, it would have a larger possibility of being right than
+   just 50/50.  In other words, if the returned critical additional data
+   would have to be selected somehow, using something more sophisticated
+   than a random process would seem justifiable.
+
+
+   The problem of too much additional data seems to be an operational
+   one: the zone administrator entering too many records which will be
+   returned either truncated or missing some RRsets to the users.  A
+   protocol fix for this is using EDNS0 [RFC2671] to signal the capacity
+   for larger UDP packet sizes, pushing up the relevant threshold.
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 11]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   Further, DNS server implementations should rather omit courtesy
+   additional data completely rather than including only some RRsets
+   [RFC2181].  An operational fix for this is having the DNS server
+   implementations return a warning when the administrators create zones
+   which would result in too much additional data being returned.
+   Further, DNS server implementations should warn of or disallow such
+   zone configurations which are recursive or otherwise difficult to
+   manage by the protocol.
+
+
+   Additionally, to avoid the case where an application would not get an
+   address at all due to some of "courtesy" additional data being
+   omitted, the resolvers should be able to query the specific records
+   of the desired protocol, not just rely on getting all the required
+   RRsets in the additional section.
+
+
+4.5  The Use of TTL for IPv4 and IPv6 RRs
+
+
+   In the previous section, we discussed a danger with queries,
+   potentially leading to omitting RRsets from the additional section;
+   this could happen to both critical and "courtesy" additional data.
+   This section discusses another problem with the latter, leading to
+   omitting RRsets in cached data, highlighted in the IPv4/IPv6
+   environment.
+
+
+   The behaviour of DNS caching when different TTL values are used for
+   different RRsets of the same name requires explicit discussion.  For
+   example, let's consider a part of a zone:
+
+
+      example.com.        300    IN    MX     foo.example.com.
+      foo.example.com.    300    IN    A      192.0.2.1
+      foo.example.com.    100    IN    AAAA   2001:db8::1
+
+
+   When a caching resolver asks for the MX record of example.com, it
+   gets back "foo.example.com".  It may also get back either one or both
+   of the A and AAAA records in the additional section.  So, there are
+   three cases about returning records for the MX in the additional
+   section:
+
+
+   1.  We get back no A or AAAA RRsets: this is the simplest case,
+       because then we have to query which information is required
+       explicitly, guaranteeing that we get all the information we're
+       interested in.
+
+
+   2.  We get back all the RRsets: this is an optimization as there is
+       no need to perform more queries, causing lower latency.  However,
+       it is impossible to guarantee that in fact we would always get
+       back all the records (the only way to ensure that is to send a
+       AAAA query for the name after getting the cached reply with A
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 12]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+       records or vice versa).
+
+
+   3.  We only get back A or AAAA RRsets even if both existed: this is
+       indistinguishable from the previous case, and may have problems
+       at least in certain environments as described in the previous
+       section.
+
+
+   As the third case was considered in the previous section, we assume
+   we get back both A and AAAA records of foo.example.com, or the stub
+   resolver explicitly asks, in two separate queries, both A and AAAA
+   records.
+
+
+   After 100 seconds, the AAAA record is removed from the cache(s)
+   because its TTL expired.  It could be argued to be useful for the
+   caching resolvers to discard the A record when the shorter TTL (in
+   this case, for the AAAA record) expires; this would avoid the
+   situation where there would be a window of 200 seconds when
+   incomplete information is returned from the cache.  The behaviour in
+   this scenario is unspecified.
+
+
+   To simplify the situation, it might help to use the same TTL for all
+   the resource record sets referring to the same name, unless there is
+   a particular reason for not doing so.  However, there are some
+   scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
+   a different strategy is preferable.
+
+
+   Thus, applications that use the response should not rely on a
+   particular TTL configuration.  For example, even if an application
+   gets a response that only has the A record in the example described
+   above, it should be still aware that there could be a AAAA record for
+   "foo.example.com".  That is, the application should try to fetch the
+   missing records itself if it needs the record.
+
+
+4.6  IPv6 Transport Guidelines for DNS Servers
+
+
+   As described in Section 1.3 and
+   [I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue to
+   be at least one authoritative IPv4 DNS server for every zone, even if
+   the zone has only IPv6 records.  (Note that obviously, having more
+   servers with robust connectivity would be preferable, but this is the
+   minimum recommendation; also see [RFC2182].)
+
+
+5.  Recommendations for DNS Resolver IPv6 Support
+
+
+   When IPv6 is enabled on a node, there are several things to consider
+   to ensure that the process is as smooth as possible.
+
+
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 13]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+5.1  DNS Lookups May Query IPv6 Records Prematurely
+
+
+   The system library that implements the getaddrinfo() function for
+   looking up names is a critical piece when considering the robustness
+   of enabling IPv6; it may come in basically three flavours:
+
+
+   1.  The system library does not know whether IPv6 has been enabled in
+       the kernel of the operating system: it may start looking up AAAA
+       records with getaddrinfo() and AF_UNSPEC hint when the system is
+       upgraded to a system library version which supports IPv6.
+
+
+   2.  The system library might start to perform IPv6 queries with
+       getaddrinfo() only when IPv6 has been enabled in the kernel.
+       However, this does not guarantee that there exists any useful
+       IPv6 connectivity (e.g., the node could be isolated from the
+       other IPv6 networks, only having link-local addresses).
+
+
+   3.  The system library might implement a toggle which would apply
+       some heuristics to the "IPv6-readiness" of the node before
+       starting to perform queries; for example, it could check whether
+       only link-local IPv6 address(es) exists, or if at least one
+       global IPv6 address exists.
+
+
+   First, let us consider generic implications of unnecessary queries
+   for AAAA records: when looking up all the records in the DNS, AAAA
+   records are typically tried first, and then A records.  These are
+   done in serial, and the A query is not performed until a response is
+   received to the AAAA query.  Considering the misbehaviour of DNS
+   servers and load-balancers, as described in Section 3.1, the look-up
+   delay for AAAA may incur additional unnecessary latency, and
+   introduce a component of unreliability.
+
+
+   One option here could be to do the queries partially in parallel; for
+   example, if the final response to the AAAA query is not received in
+   0.5 seconds, start performing the A query while waiting for the
+   result (immediate parallelism might be unoptimal, at least without
+   information sharing between the look-up threads, as that would
+   probably lead to duplicate non-cached delegation chain lookups).
+
+
+   An additional concern is the address selection, which may, in some
+   circumstances, prefer AAAA records over A records even when the node
+   does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
+   In some cases, the implementation may attempt to connect or send a
+   datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
+   incurring very long protocol timeouts, instead of quickly failing
+   back to IPv4.
+
+
+   Now, we can consider the issues specific to each of the three
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 14]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   possibilities:
+
+
+   In the first case, the node performs a number of completely useless
+   DNS lookups as it will not be able to use the returned AAAA records
+   anyway.  (The only exception is where the application desires to know
+   what's in the DNS, but not use the result for communication.)  One
+   should be able to disable these unnecessary queries, for both latency
+   and reliability reasons.  However, as IPv6 has not been enabled, the
+   connections to IPv6 addresses fail immediately, and if the
+   application is programmed properly, the application can fall
+   gracefully back to IPv4 [I-D.ietf-v6ops-application-transition].
+
+
+   The second case is similar to the first, except it happens to a
+   smaller set of nodes when IPv6 has been enabled but connectivity has
+   not been provided yet; similar considerations apply, with the
+   exception that IPv6 records, when returned, will be actually tried
+   first which may typically lead to long timeouts.
+
+
+   The third case is a bit more complex: optimizing away the DNS lookups
+   with only link-locals is probably safe (but may be desirable with
+   different lookup services which getaddrinfo() may support), as the
+   link-locals are typically automatically generated when IPv6 is
+   enabled, and do not indicate any form of IPv6 connectivity.  That is,
+   performing DNS lookups only when a non-link-local address has been
+   configured on any interface could be beneficial -- this would be an
+   indication that either the address has been configured either from a
+   router advertisement, DHCPv6 [RFC3315], or manually.  Each would
+   indicate at least some form of IPv6 connectivity, even though there
+   would not be guarantees of it.
+
+
+   These issues should be analyzed at more depth, and the fixes found
+   consensus on, perhaps in a separate document.
+
+
+5.2  Obtaining a List of DNS Recursive Resolvers
+
+
+   In scenarios where DHCPv6 is available, a host can discover a list of
+   DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
+   option [RFC3646].  This option can be passed to a host through a
+   subset of DHCPv6 [RFC3736].
+
+
+   The IETF is considering the development of alternative mechanisms for
+   obtaining the list of DNS recursive name servers when DHCPv6 is
+   unavailable or inappropriate.  No decision about taking on this
+   development work has been reached as of this writing (Aug 2004)
+   [I-D.ietf-dnsop-ipv6-dns-configuration].
+
+
+   In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
+   under consideration for development include the use of well-known
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 15]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   addresses [I-D.ohta-preconfigured-dns] and the use of Router
+   Advertisements to convey the information
+   [I-D.jeong-dnsop-ipv6-dns-discovery].
+
+
+   Note that even though IPv6 DNS resolver discovery is a recommended
+   procedure, it is not required for dual-stack nodes in dual-stack
+   networks as IPv6 DNS records can be queried over IPv4 as well as
+   IPv6.  Obviously, nodes which are meant to function without manual
+   configuration in IPv6-only networks must implement the DNS resolver
+   discovery function.
+
+
+5.3  IPv6 Transport Guidelines for Resolvers
+
+
+   As described in Section 1.3 and
+   [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers
+   should be IPv4-only or dual-stack to be able to reach any IPv4-only
+   DNS server.  Note that this requirement is also fulfilled by an
+   IPv6-only stub resolver pointing to a dual-stack recursive DNS
+   resolver.
+
+
+6.  Considerations about Forward DNS Updating
+
+
+   While the topic how to enable updating the forward DNS, i.e., the
+   mapping from names to the correct new addresses, is not specific to
+   IPv6, it should be considered especially due to the advent of
+   Stateless Address Autoconfiguration [RFC2462].
+
+
+   Typically forward DNS updates are more manageable than doing them in
+   the reverse DNS, because the updater can often be assumed to "own" a
+   certain DNS name -- and we can create a form of security relationship
+   with the DNS name and the node which is allowed to update it to point
+   to a new address.
+
+
+   A more complex form of DNS updates -- adding a whole new name into a
+   DNS zone, instead of updating an existing name -- is considered out
+   of scope for this memo as it could require zone-wide authentication.
+   Adding a new name in the forward zone is a problem which is still
+   being explored with IPv4, and IPv6 does not seem to add much new in
+   that area.
+
+
+6.1  Manual or Custom DNS Updates
+
+
+   The DNS mappings can also be maintained by hand, in a semi-automatic
+   fashion or by running non-standardized protocols.  These are not
+   considered at more length in this memo.
+
+
+
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 16]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+6.2  Dynamic DNS
+
+
+   Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized
+   mechanism for dynamically updating the DNS.  It works equally well
+   with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
+   address configuration.  It is important to consider how each of these
+   behave if IP address-based authentication, instead of stronger
+   mechanisms [RFC3007], was used in the updates.
+
+
+   1.  manual addresses are static and can be configured
+
+
+   2.  DHCPv6 addresses could be reasonably static or dynamic, depending
+       on the deployment, and could or could not be configured on the
+       DNS server for the long term
+
+
+   3.  SLAAC addresses are typically stable for a long time, but could
+       require work to be configured and maintained.
+
+
+   As relying on IP addresses for Dynamic DNS is rather insecure at
+   best, stronger authentication should always be used; however, this
+   requires that the authorization keying will be explicitly configured
+   using unspecified operational methods.
+
+
+   Note that with DHCP it is also possible that the DHCP server updates
+   the DNS, not the host.  The host might only indicate in the DHCP
+   exchange which hostname it would prefer, and the DHCP server would
+   make the appropriate updates.  Nonetheless, while this makes setting
+   up a secure channel between the updater and the DNS server easier, it
+   does not help much with "content" security, i.e., whether the
+   hostname was acceptable -- if the DNS server does not include
+   policies, they must be included in the DHCP server (e.g., a regular
+   host should not be able to state that its name is "www.example.com").
+   DHCP-initiated DDNS updates have been extensively described in
+   [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
+   [I-D.ietf-dnsext-dhcid-rr].
+
+
+   The nodes must somehow be configured with the information about the
+   servers where they will attempt to update their addresses, sufficient
+   security material for authenticating themselves to the server, and
+   the hostname they will be updating.  Unless otherwise configured, the
+   first could be obtained by looking up the authoritative name servers
+   for the hostname; the second must be configured explicitly unless one
+   chooses to trust the IP address-based authentication (not a good
+   idea); and lastly, the nodename is typically pre-configured somehow
+   on the node, e.g., at install time.
+
+
+   Care should be observed when updating the addresses not to use longer
+   TTLs for addresses than are preferred lifetimes for the addresses, so
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 17]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   that if the node is renumbered in a managed fashion, the amount of
+   stale DNS information is kept to the minimum.  That is, if the
+   preferred lifetime of an address expires, the TTL of the record needs
+   be modified unless it was already done before the expiration.  For
+   better flexibility, the DNS TTL should be much shorter (e.g., a half
+   or a third) than the lifetime of an address; that way, the node can
+   start lowering the DNS TTL if it seems like the address has not been
+   renewed/refreshed in a while.  Some discussion on how an
+   administrator could manage the DNS TTL is included in
+   [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to
+   (smart) hosts as well.
+
+
+7.  Considerations about Reverse DNS Updating
+
+
+   Updating the reverse DNS zone may be difficult because of the split
+   authority over an address.  However, first we have to consider the
+   applicability of reverse DNS in the first place.
+
+
+7.1  Applicability of Reverse DNS
+
+
+   Today, some applications use reverse DNS to either look up some hints
+   about the topological information associated with an address (e.g.
+   resolving web server access logs), or as a weak form of a security
+   check, to get a feel whether the user's network administrator has
+   "authorized" the use of the address (on the premises that adding a
+   reverse record for an address would signal some form of
+   authorization).
+
+
+   One additional, maybe slightly more useful usage is ensuring that the
+   reverse and forward DNS contents match (by looking up the pointer to
+   the name by the IP address from the reverse tree, and ensuring that a
+   record under the name in the forward tree points to the IP address)
+   and correspond to a configured name or domain.  As a security check,
+   it is typically accompanied by other mechanisms, such as a user/
+   password login; the main purpose of the reverse+forward DNS check is
+   to weed out the majority of unauthorized users, and if someone
+   managed to bypass the checks, he would still need to authenticate
+   "properly".
+
+
+   It may also be desirable to store IPsec keying material corresponding
+   to an IP address to the reverse DNS, as justified and described in
+   [I-D.ietf-ipseckey-rr].
+
+
+   It is not clear whether it makes sense to require or recommend that
+   reverse DNS records be updated.  In many cases, it would just make
+   more sense to use proper mechanisms for security (or topological
+   information lookup) in the first place.  At minimum, the applications
+   which use it as a generic authorization (in the sense that a record
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 18]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   exists at all) should be modified as soon as possible to avoid such
+   lookups completely.
+
+
+   The applicability is discussed at more length in
+   [I-D.ietf-dnsop-inaddr-required].
+
+
+7.2  Manual or Custom DNS Updates
+
+
+   Reverse DNS can of course be updated using manual or custom methods.
+   These are not further described here, except for one special case.
+
+
+   One way to deploy reverse DNS would be to use wildcard records, for
+   example, by configuring one name for a subnet (/64) or a site (/48).
+   As a concrete example, a site (or the site's ISP) could configure the
+   reverses of the prefix 2001:db8:f00::/48 to point to one name using a
+   wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN PTR
+   site.example.com." Naturally, such a name could not be verified from
+   the forward DNS, but would at least provide some form of "topological
+   information" or "weak authorization" if that is really considered to
+   be useful.  Note that this is not actually updating the DNS as such,
+   as the whole point is to avoid DNS updates completely by manually
+   configuring a generic name.
+
+
+7.3  DDNS with Stateless Address Autoconfiguration
+
+
+   Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
+   some regard, while being more difficult in another, as described
+   below.
+
+
+   The address space administrator decides whether the hosts are trusted
+   to update their reverse DNS records or not.  If they are, a simple
+   address-based authorization is typically sufficient (i.e., check that
+   the DNS update is done from the same IP address as the record being
+   updated); stronger security can also be used [RFC3007].  If they
+   aren't allowed to update the reverses, no update can occur.  (Such
+   address-based update authorization operationally requires that
+   ingress filtering [RFC3704] has been set up at the border of the site
+   where the updates occur, and as close to the updater as possible.)
+
+
+   Address-based authorization is simpler with reverse DNS (as there is
+   a connection between the record and the address) than with forward
+   DNS.  However, when a stronger form of security is used, forward DNS
+   updates are simpler to manage because the host can be assumed to have
+   an association with the domain.  Note that the user may roam to
+   different networks, and does not necessarily have any association
+   with the owner of that address space -- so, assuming stronger form of
+   authorization for reverse DNS updates than an address association is
+   generally unfeasible.
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 19]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   Moreover, the reverse zones must be cleaned up by an unspecified
+   janitorial process: the node does not typically know a priori that it
+   will be disconnected, and cannot send a DNS update using the correct
+   source address to remove a record.
+
+
+   A problem with defining the clean-up process is that it is difficult
+   to ensure that a specific IP address and the corresponding record are
+   no longer being used.  Considering the huge address space, and the
+   unlikelihood of collision within 64 bits of the interface
+   identifiers, a process which would remove the record after no traffic
+   has been seen from a node in a long period of time (e.g., a month or
+   year) might be one possible approach.
+
+
+   To insert or update the record, the node must discover the DNS server
+   to send the update to somehow, similar to as discussed in Section
+   6.2.  One way to automate this is looking up the DNS server
+   authoritative (e.g., through SOA record) for the IP address being
+   updated, but the security material (unless the IP address-based
+   authorization is trusted) must also be established by some other
+   means.
+
+
+   One should note that Cryptographically Generated Addresses
+   [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of
+   treatment.  CGAs are addresses where the interface identifier is
+   calculated from a public key, a modifier (used as a nonce), the
+   subnet prefix, and other data.  Depending on the usage profile, CGAs
+   might or might not be changed periodically due to e.g., privacy
+   reasons.  As the CGA address is not predicatable, a reverse record
+   can only reasonably be inserted in the DNS by the node which
+   generates the address.
+
+
+7.4  DDNS with DHCP
+
+
+   With DHCPv4, the reverse DNS name is typically already inserted to
+   the DNS that reflects to the name (e.g., "dhcp-67.example.com").  One
+   can assume similar practice may become commonplace with DHCPv6 as
+   well; all such mappings would be pre-configured, and would require no
+   updating.
+
+
+   If a more explicit control is required, similar considerations as
+   with SLAAC apply, except for the fact that typically one must update
+   a reverse DNS record instead of inserting one (if an address
+   assignment policy that reassigns disused addresses is adopted) and
+   updating a record seems like a slightly more difficult thing to
+   secure.  However, it is yet uncertain how DHCPv6 is going to be used
+   for address assignment.
+
+
+   Note that when using DHCP, either the host or the DHCP server could
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 20]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   perform the DNS updates; see the implications in Section 6.2.
+
+
+   If disused addresses were to be reassigned, host-based DDNS reverse
+   updates would need policy considerations for DNS record modification,
+   as noted above.  On the other hand, if disused address were not to be
+   assigned, host-based DNS reverse updates would have similar
+   considerations as SLAAC in Section 7.3.  Server-based updates have
+   similar properties except that the janitorial process could be
+   integrated with DHCP address assignment.
+
+
+7.5  DDNS with Dynamic Prefix Delegation
+
+
+   In cases where a prefix, instead of an address, is being used and
+   updated, one should consider what is the location of the server where
+   DDNS updates are made.  That is, where the DNS server is located:
+
+
+   1.  At the same organization as the prefix delegator.
+
+
+   2.  At the site where the prefixes are delegated to.  In this case,
+       the authority of the DNS reverse zone corresponding to the
+       delegated prefix is also delegated to the site.
+
+
+   3.  Elsewhere; this implies a relationship between the site and where
+       DNS server is located, and such a relationship should be rather
+       straightforward to secure as well.  Like in the previous case,
+       the authority of the DNS reverse zone is also delegated.
+
+
+   In the first case, managing the reverse DNS (delegation) is simpler
+   as the DNS server and the prefix delegator are in the same
+   administrative domain (as there is no need to delegate anything at
+   all); alternatively, the prefix delegator might forgo DDNS reverse
+   capability altogether, and use e.g., wildcard records (as described
+   in Section 7.2).  In the other cases, it can be slighly more
+   difficult, particularly as the site will have to configure the DNS
+   server to be authoritative for the delegated reverse zone, implying
+   automatic configuration of the DNS server -- as the prefix may be
+   dynamic.
+
+
+   Managing the DDNS reverse updates is typically simple in the second
+   case, as the updated server is located at the local site, and
+   arguably IP address-based authentication could be sufficient (or if
+   not, setting up security relationships would be simpler).  As there
+   is an explicit (security) relationship between the parties in the
+   third case, setting up the security relationships to allow reverse
+   DDNS updates should be rather straightforward as well (but IP
+   address-based authentication might not be acceptable).  In the first
+   case, however, setting up and managing such relationships might be a
+   lot more difficult.
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 21]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+8.  Miscellaneous DNS Considerations
+
+
+   This section describes miscellaneous considerations about DNS which
+   seem related to IPv6, for which no better place has been found in
+   this document.
+
+
+8.1  NAT-PT with DNS-ALG
+
+
+   The DNS-ALG component of NAT-PT mangles A records  to look like AAAA
+   records to the IPv6-only nodes.  Numerous problems have been
+   identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues].
+   This is a strong reason not to use NAT-PT in the first place.
+
+
+8.2  Renumbering Procedures and Applications' Use of DNS
+
+
+   One of the most difficult problems of systematic IP address
+   renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
+   an application which looks up a DNS name disregards information such
+   as TTL, and uses the result obtained from DNS as long as it happens
+   to be stored in the memory of the application.  For applications
+   which run for a long time, this could be days, weeks or even months;
+   some applications may be clever enough to organize the data
+   structures and functions in such a manner that look-ups get refreshed
+   now and then.
+
+
+   While the issue appears to have a clear solution, "fix the
+   applications", practically this is not reasonable immediate advice;
+   the TTL information is not typically available in the APIs and
+   libraries (so, the advice becomes "fix the applications, APIs and
+   libraries"), and a lot more analysis is needed on how to practically
+   go about to achieve the ultimate goal of avoiding using the names
+   longer than expected.
+
+
+9.  Acknowledgements
+
+
+   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
+   provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
+   Nordmark and Bob Gilligan.  Havard Eidnes and Michael Patton provided
+   useful feedback and improvements.  Scott Rose, Rob Austein, Masataka
+   Ohta, and Mark Andrews helped in clarifying the issues regarding
+   additional data and the use of TTL.  Jefsey Morfin, Ralph Droms,
+   Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
+   Rob Austein provided useful feedback during the WG last call.  Thomas
+   Narten provided extensive feedback during the IESG evaluation.
+
+
+10.  Security Considerations
+
+
+   This document reviews the operational procedures for IPv6 DNS
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 22]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   operations and does not have security considerations in itself.
+
+
+   However, it is worth noting that in particular with Dynamic DNS
+   Updates, security models based on the source address validation are
+   very weak and cannot be recommended -- they could only be considered
+   in the environments where ingress filtering [RFC3704] has been
+   deployed.  On the other hand, it should be noted that setting up an
+   authorization mechanism (e.g., a shared secret, or public-private
+   keys) between a node and the DNS server has to be done manually, and
+   may require quite a bit of time and expertise.
+
+
+   To re-emphasize which was already stated, the reverse+forward DNS
+   check provides very weak security at best, and the only
+   (questionable) security-related use for them may be in conjunction
+   with other mechanisms when authenticating a user.
+
+
+11.  References
+
+
+11.1  Normative References
+
+
+   [I-D.ietf-dnsop-ipv6-dns-configuration]
+              Jeong, J., "IPv6 Host Configuration of DNS Server
+              Information Approaches",
+              draft-ietf-dnsop-ipv6-dns-configuration-02 (work in
+              progress), July 2004.
+
+
+   [I-D.ietf-dnsop-ipv6-transport-guidelines]
+              Durand, A. and J. Ihren, "DNS IPv6 transport operational
+              guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02
+              (work in progress), March 2004.
+
+
+   [I-D.ietf-dnsop-misbehavior-against-aaaa]
+              Morishita, Y. and T. Jinmei, "Common Misbehavior against
+              DNS Queries for IPv6 Addresses",
+              draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in
+              progress), April 2004.
+
+
+   [I-D.ietf-ipv6-deprecate-site-local]
+              Huitema, C. and B. Carpenter, "Deprecating Site Local
+              Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work
+              in progress), March 2004.
+
+
+   [I-D.ietf-v6ops-application-transition]
+              Shin, M., "Application Aspects of IPv6 Transition",
+              draft-ietf-v6ops-application-transition-03 (work in
+              progress), June 2004.
+
+
+   [I-D.ietf-v6ops-renumbering-procedure]
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 23]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+              Baker, F., Lear, E. and R. Droms, "Procedures for
+              Renumbering an IPv6 Network without a Flag Day",
+              draft-ietf-v6ops-renumbering-procedure-01 (work in
+              progress), July 2004.
+
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+              April 1997.
+
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+
+   [RFC2182]  Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
+              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
+              July 1997.
+
+
+   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
+              Autoconfiguration", RFC 2462, December 1998.
+
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+
+   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
+              Stateless Address Autoconfiguration in IPv6", RFC 3041,
+              January 2001.
+
+
+   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+              via IPv4 Clouds", RFC 3056, February 2001.
+
+
+   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+              August 2001.
+
+
+   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
+              M. Carney, "Dynamic Host Configuration Protocol for IPv6
+              (DHCPv6)", RFC 3315, July 2003.
+
+
+   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T.
+              Hain, "Representing Internet Protocol version 6 (IPv6)
+              Addresses in the Domain Name System (DNS)", RFC 3363,
+              August 2002.
+
+
+   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
+              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
+              August 2002.
+
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 24]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+              (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
+              Extensions to Support IP Version 6", RFC 3596, October
+              2003.
+
+
+   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
+              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+              December 2003.
+
+
+   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
+              (DHCP) Service for IPv6", RFC 3736, April 2004.
+
+
+11.2  Informative References
+
+
+   [I-D.durand-v6ops-natpt-dns-alg-issues]
+              Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
+              draft-durand-v6ops-natpt-dns-alg-issues-00 (work in
+              progress), February 2003.
+
+
+   [I-D.huitema-v6ops-teredo]
+              Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              NATs", draft-huitema-v6ops-teredo-02 (work in progress),
+              June 2004.
+
+
+   [I-D.huston-6to4-reverse-dns]
+              Huston, G., "6to4 Reverse DNS",
+              draft-huston-6to4-reverse-dns-02 (work in progress), April
+              2004.
+
+
+   [I-D.ietf-dhc-ddns-resolution]
+              Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
+              Clients", draft-ietf-dhc-ddns-resolution-07 (work in
+              progress), July 2004.
+
+
+   [I-D.ietf-dhc-fqdn-option]
+              Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
+              draft-ietf-dhc-fqdn-option-07 (work in progress), July
+              2004.
+
+
+   [I-D.ietf-dnsext-dhcid-rr]
+              Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for
+              encoding DHCP information (DHCID RR)",
+              draft-ietf-dnsext-dhcid-rr-08 (work in progress), July
+              2004.
+
+
+   [I-D.ietf-dnsop-bad-dns-res]
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 25]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+              Larson, M. and P. Barber, "Observed DNS Resolution
+              Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in
+              progress), July 2004.
+
+
+   [I-D.ietf-dnsop-dontpublish-unreachable]
+              Hazel, P., "IP Addresses that should never appear in the
+              public DNS", draft-ietf-dnsop-dontpublish-unreachable-03
+              (work in progress), February 2002.
+
+
+   [I-D.ietf-dnsop-inaddr-required]
+              Senie, D., "Requiring DNS IN-ADDR Mapping",
+              draft-ietf-dnsop-inaddr-required-05 (work in progress),
+              April 2004.
+
+
+   [I-D.ietf-ipseckey-rr]
+              Richardson, M., "A method for storing IPsec keying
+              material in DNS", draft-ietf-ipseckey-rr-11 (work in
+              progress), July 2004.
+
+
+   [I-D.ietf-ipv6-unique-local-addr]
+              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in
+              progress), June 2004.
+
+
+   [I-D.ietf-send-cga]
+              Aura, T., "Cryptographically Generated Addresses (CGA)",
+              draft-ietf-send-cga-06 (work in progress), April 2004.
+
+
+   [I-D.ietf-v6ops-3gpp-analysis]
+              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
+              Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in
+              progress), May 2004.
+
+
+   [I-D.ietf-v6ops-mech-v2]
+              Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-04
+              (work in progress), July 2004.
+
+
+   [I-D.ietf-v6ops-onlinkassumption]
+              Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
+              On-Link Assumption Considered Harmful",
+              draft-ietf-v6ops-onlinkassumption-02 (work in progress),
+              May 2004.
+
+
+   [I-D.ietf-v6ops-v6onbydefault]
+              Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack
+              IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
+              (work in progress), July 2004.
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 26]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   [I-D.jeong-dnsop-ipv6-dns-discovery]
+              Jeong, J., "IPv6 DNS Discovery based on Router
+              Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02
+              (work in progress), July 2004.
+
+
+   [I-D.moore-6to4-dns]
+              Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
+              in progress), October 2002.
+
+
+   [I-D.ohta-preconfigured-dns]
+              Ohta, M., "Preconfigured DNS Server Addresses",
+              draft-ohta-preconfigured-dns-01 (work in progress),
+              February 2004.
+
+
+   [I-D.savola-v6ops-6bone-mess]
+              Savola, P., "Moving from 6bone to IPv6 Internet",
+              draft-savola-v6ops-6bone-mess-01 (work in progress),
+              November 2002.
+
+
+   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
+              Translation - Protocol Translation (NAT-PT)", RFC 2766,
+              February 2000.
+
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+
+   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
+              Unique DNS Root", RFC 2826, May 2000.
+
+
+   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
+              Networks", BCP 84, RFC 3704, March 2004.
+
+
+
+Authors' Addresses
+
+
+   Alain Durand
+   SUN Microsystems, Inc.
+   17 Network circle UMPL17-202
+   Menlo Park, CA  94025
+   USA
+
+
+   EMail: Alain.Durand@sun.com
+
+
+
+
+
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 27]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   Johan Ihren
+   Autonomica
+   Bellmansgatan 30
+   SE-118 47 Stockholm
+   Sweden
+
+
+   EMail: johani@autonomica.se
+
+
+
+   Pekka Savola
+   CSC/FUNET
+   Espoo
+   Finland
+
+
+   EMail: psavola@funet.fi
+
+
+Appendix A.  Site-local Addressing Considerations for DNS
+
+
+   As site-local addressing has been deprecated, the considerations for
+   site-local addressing are discussed briefly here.  Unique local
+   addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed
+   as a replacement, but being work-in-progress, it is not considered
+   further.
+
+
+   The interactions with DNS come in two flavors: forward and reverse
+   DNS.
+
+
+   To actually use site-local addresses within a site, this implies the
+   deployment of a "split-faced" or a fragmented DNS name space, for the
+   zones internal to the site, and the outsiders' view to it.  The
+   procedures to achieve this are not elaborated here.  The implication
+   is that site-local addresses must not be published in the public DNS.
+
+
+   To faciliate reverse DNS (if desired) with site-local addresses, the
+   stub resolvers must look for DNS information from the local DNS
+   servers, not e.g.  starting from the root servers, so that the
+   site-local information may be provided locally.  Note that the
+   experience of private addresses in IPv4 has shown that the root
+   servers get loaded for requests for private address lookups in any
+   case.
+
+
+Appendix B.  Issues about Additional Data or TTL
+
+
+   [[ note to the RFC-editor: remove this section upon publication.  ]]
+
+
+   This appendix tries to describe the apparent rought consensus about
+   additional data and TTL issues (sections 4.4 and 4.5), and present
+   questions when there appears to be no consensus.  The point of
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 28]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+   recording them here is to focus the discussion and get feedback.
+
+
+   Resolved:
+
+
+   a.  If some critical additional data RRsets wouldn't fit, you set the
+       TC bit even if some RRsets did fit.
+
+
+   b.  If some courtesy additional data RRsets wouldn't fit, you never
+       set the TC bit, but rather remove (at least some of) the courtesy
+       RRsets.
+
+
+   c.  DNS servers should implement sanity checks on the resulting glue,
+       e.g., to disable circular dependencies.  Then the responding
+       servers can use at-or-below-a-zone-cut criterion to determine
+       whether the additional data is critical or not.
+
+
+   Open issues (at least):
+
+
+   1.  if some critical additional data RRsets would fit, but some
+       wouldn't, and TC has to be set (see above), should one rather
+       remove the additional data that did fit, keep it, or leave
+       unspecified?
+
+
+   2.  if some courtesy additional data RRsets would fit, but some
+       wouldn't, and some will have to be removed from the response (no
+       TC is set, see above), what to do -- remove all courtesy RRsets,
+       keep all that fit, or leave unspecified?
+
+
+   3.  is it acceptable to use the transport used in the DNS query as a
+       hint which records to keep if not removing all the RRsets, if: a)
+       having to decide which critical additional data to keep, or b)
+       having to decide which courtesy additional data to keep?
+
+
+   4.  (this issue was discussed in section 4.5) if one RRset has TTL of
+       100 seconds, and another the TTL of 300 seconds, what should the
+       caching server do after 100 seconds?  Keep returning just one
+       RRset when returning additional data, or discard the other RRset
+       from the cache?
+
+
+   5.  how do we move forward from here?  If we manage to get to some
+       form of consensus, how do we record it: a) just in
+       draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational
+       category only!), b) a separate BCP or similar by DNSEXT WG(?),
+       clarifying and giving recommendations, c) something else, what?
+
+
+
+
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 29]
+Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+Durand, et al.          Expires February 7, 2005               [Page 30]
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-00.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-00.txt
deleted file mode 100644
index 77e68d91..00000000
--- a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-00.txt
+++ /dev/null
@@ -1,447 +0,0 @@
-
-DNSOP                                                          G. Guette
-Internet-Draft                                        IRISA/INRIA Rennes
-Expires: August 8, 2004                                       O. Courtay
-                                                           ENST-Bretagne
-                                                        February 8, 2004
-
-
-            Requirements for Automated Key Rollover in DNSsec
-              draft-ietf-dnsop-key-rollover-requirements-00
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 8, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-   This document describes problems that appear during an automated
-   rollover and gives the requirements for the design of communication
-   between parent zone and child zone in an automated rollover process.
-   This document is essentially about key rollover, the rollover of
-   one other Resource Record present at delegation point (NS RR) is
-   also discussed.
-
-	
-
-	
-
-	
-
-Guette & Courtay             Expires August 8, 2004             [Page 1]
-
-Internet-Draft       Automated Rollover Requirements       February 2004
-
-
-1. Introduction
-
-   The DNS security extensions (DNSsec) [1] uses public-key cryptography
-   and digital signatures. It stores the public keys in KEY Resource
-   Records (RRs). Because old keys and frequently used keys are
-   vulnerable, they must be changed periodically. In DNSsec this is the
-   case for Zone Signing Keys (ZSKs) and Key Signing Keys (KSKs) [2, 4].
-   Automation of key rollover process is necessary for large zones
-   because inside a large zone, there are too many changes to handle for
-   a single administrator.
-   
-   Let us consider for example a zone with one million child zones among
-   which only 10% of secured child zones. If the child zones change their
-   keys once a year on average, that implies 300 changes per day for the
-   parent zone. All these changes are hard to manage manually.
-   
-   Automated rollover is optional and resulting from an agreement 
-   between the administrator of the parent zone and the administrator of
-   the child zone. Of course, key rollover can also be done manually by
-   administrators.
-
-   This document describes the requirements for the design of messages
-   of automated key rollover process.
-
-	 
-2. The Key Rollover Process
-
-   Key rollover consists in replacing the DNSsec keys used to sign
-   resource records in a given DNS zone file. There are two types of
-   rollover, ZSK rollover and KSK rollover.
-   In ZSK rollover, all changes are local to the zone that changes its
-   key: there is no need to contact other zones (e.g. parent zone) to
-   propagate the performed changes because this type of key have no
-   associated DS records in the parent zone.
-   In KSK rollover, new DS RR(s) MUST be created and stored in the
-   parent zone. In consequence, the child zone MUST contact its parent
-   zone and notify it about the KSK change(s).
-	
-   Manual key rollover exists and works [3]. The key rollover is built
-   from two parts of different nature:
-    - An algorithm that generates new keys. It could be local to the
-      zone
-    - The interaction between parent and child zone
-
-   In this document we focus on the interaction between parent and
-   child zone servers.
-   One example of manual key rollover is:
-   Child zone creates a new KSK, waiting for the creation of the DS
-      
-	 
-	
-Guette & Courtay             Expires August 8, 2004             [Page 2]
-
-Internet-Draft       Automated Rollover Requirements       February 2004
-
-
-   record in its parent zone and then child zone deletes old key.
-
-   In manual rollover, communications are managed by the zone
-   administrators and the security of these communications is out of
-   scope of DNSsec.
-
-   Automated key rollover MUST use a secure communication between parent
-   and child zone. In this document we concentrate our efforts on
-   defining interactions between entities present in key rollover
-   process that are not	explicitly defined in manual key rollover
-   method.
-   
-	
-3. Basic Requirements
-
-   The main constraint to respect during a key rollover is that the
-   chain of trust MUST be preserved. Even if a resolver retrieve some RRs
-   from recursive name server. Every RR MUST be verifiable at any time,
-   every message exchanged during rollover MUST be authenticated and
-   data integrity MUST be guaranteed.
-	 
-   Two entities are present during a KSK rollover: the child zone and
-   its parent zone. These zones are generally managed by different
-   administrators. These administrators MUST agree on some parameters
-   like availability of automated rollover, the maximum delay between
-   notification of changes in the child zone and the resigning of the
-   parent zone. The child zone needs to know this delay to schedule its
-   changes.
-   
-   During an automated rollover process, data are transmitted between
-   the primary name server of the parent and the the primary name server
-   of the child zone.
-   The reason is that the IP address of the primary name server is easy
-   to obtain.
-   Other solutions based on machine dedicated to the rollover are not
-   suitable solutions because of the difficulty to obtain the IP
-   addresses of the dedicated machine in an automated manner.
-
-	 
-4. Messages authentication and information exchanged
-
-   Every exchanged message MUST be authenticated and the authentication
-   tool MUST be a DNSsec tool such as TSIG [5], SIG(0) [6] or DNSsec
-   request with verifiable SIG records.
- 	 
-   Once the changes related to a KSK are made in a child zone, this zone
-     
-   
-
-	 
-Guette & Courtay             Expires August 8, 2004             [Page 3]
-
-Internet-Draft       Automated Rollover Requirements       February 2004
-
-
-   MUST notify its parent zone in order to create the new DS RR and
-   store this DS RR in parent zone file.
-
-   The parent zone MUST receive all the child Keys that needs the
-   creation of an associated DS RRs in the parent zone.
-	 
-   Some errors could occur during transmission between child zone and
-   parent zone. Key rollover solution MUST be fault tolerant, i.e. at
-   any time the rollover MUST be in a consistent state and all RRs MUST
-   be verifiable, even if an error occurs. That is to say that it MUST
-   remains a valid chain of trust.
-	
-
-5. Emergency Rollover
-
-   A key of a zone might be compromised and this key MUST be changed as
-   soon as possible. Fast changes could break the chain of trust. The
-   part of DNS tree having this zone as apex can become unverifiable,
-   but the break of the chain of trust is necessary if we want to no one
-   can use the compromised key to spoof DNS data.
-
-   Parent zone behavior after an emergency rollover in one of its child
-   zone is an open discussion.
-   Should we define:
-	 
-    - an EMERGENCY flag. When a child zone does an emergency KSK change,
-      it uses the EMERGENCY flag to notify its parents that the chain of
-      trust is broken and will stay broken until right DS creation and a
-      parent zone resigning.
-   
-    - a maximum time delay after next parent zone resigning, we ensure
-      that after this delay the parent zone is resigned and the right DS
-      is created.
-   
-    - that no pre-defined behavior for the parent zone is needed
-
-
-6. Other Resource Record concerned by automatic rollover
-
-   NS records are also present at delegation point, so when the child
-   zone changes some NS records, the corresponding records at
-   delegation point in parent zone MUST be updated. NS records are
-   concerned by rollover and this rollover could be automated too. In
-   this case, when the child zone notifies its parent zone that some NS
-   records have been changed, the parent zone MUST verify that these NS
-   records are present in child zone before doing any changes in its own
-   zone file. This allow to avoid inconsistency between NS records at
-   delegation point and NS records present in the child zone.
-	
-   
-
-	 
-Guette & Courtay             Expires August 8, 2004             [Page 4]
-
-Internet-Draft       Automated Rollover Requirements       February 2004
-
-	 
-7. Security consideration
-
-   This document describes requirements to design an automated key
-   rollover in DNSsec based on DNSsec security. In the same way the, as
-   plain DNSsec, the automatic key rollover contains no mechanism
-   protecting against denial of service (DoS) resistant. The security
-   level obtain after an automatic key rollover, is the security level
-   provided by DNSsec.
-
-
-8. Acknowledgments
-   The authors want to acknowledge Mohsen Souissi, Bernard Cousin,
-   Bertrand Leonard and members of IDsA project for their contribution
-   to this document.
-
-
-Normative references
-
-   [1]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [2]  Gudmundsson, O., "Delegation Signer Resource Record",
-        draft-ietf-dnsext-delegation-signer-15 (work in progress),
-				June 2003.
-
-   [3]  Kolkman, O. and Gieben, R., "DNSSEC key operations",
-        draft-ietf-dnsext-operational-practices (work in progress),
-				June 2003.
-
-   [4]  Kolkman, O. and Schlyter, J., "KEY RR Secure Entry Point Flag"
-        draft-ietf-dnsext-keyrr-key-signing-flag-10 (work in progress),
-        September 2003.
-
-   [5]  Vixie, P., Gudmundsson, O., Eastlake, D., and Wellington, B.,
-        "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-				2845, May	2000.
-
-   [6]  Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)",
-	      RFC 2931, September 2000.
-
-   [7]  Eastlake, D.,"DNS Security Operational Considerations", RFC
-        2541, March 1999.
-
-
-
-
-
-	
-
-
-				
-Guette & Courtay             Expires August 8, 2004             [Page 5]
-
-Internet-Draft       Automated Rollover Requirements        October 2003
-
-
-Author's Addresses
-
-   Gilles Guette
-   IRISA/INRIA Rennes
-   Campus Universitaire de Beaulieu
-   35042 Rennes France
-   Phone : (33) 02 99 84 71 32
-   Fax : (33) 02 99 84 25 29
-   E-mail : gguette@irisa.fr
-
-   Olivier Courtay
-   ENST-Bretagne
-   2, rue de la ch‚taigneraie
-   35512 Cesson C‰vign‰ CEDEX France
-   Phone : (33) 02 99 84 71 31
-   Fax : (33) 02 99 84 25 29
-   olivier.courtay@enst-bretagne.fr
-
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-	 
-Guette & Courtay             Expires August 8, 2004             [Page 6]
-
-Internet-Draft       Automated Rollover Requirements       February 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Guette & Courtay             Expires August 8, 2004             [Page 7]
-
-Internet-Draft       Automated Rollover Requirements       February 2004
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-	 
-Guette & Courtay             Expires August 8, 2004             [Page 8]
-
diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
new file mode 100644
index 00000000..2311ee6c
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
@@ -0,0 +1,391 @@
+
+DNSOP                                                          G. Guette
+Internet-Draft                                             IRISA / INRIA
+Expires: February 5, 2005                                     O. Courtay
+                                                             Thomson R&D
+                                                          August 7, 2004
+
+
+           Requirements for Automated Key Rollover in DNSSEC
+           draft-ietf-dnsop-key-rollover-requirements-01.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+	 
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time. It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on February 5, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document describes problems that appear during an automated
+   rollover and gives the requirements for the design of communication
+   between parent zone and child zone in an automated rollover process.
+   This document is essentially about key rollover, the rollover of
+   another Resource Record present at delegation point (NS RR) is also
+   discussed.
+
+
+
+
+
+Guette & Courtay        Expires February 5, 2005                [Page 1]
+
+Internet-Draft      Automated Rollover Requirements          August 2004
+
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.   The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
+   3.   Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
+   4.   Messages authentication and information exchanged  . . . . . . 4
+   5.   Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
+   6.   Other Resource Record concerned by automatic rollover  . . . . 5
+   7.   Security consideration . . . . . . . . . . . . . . . . . . . . 5
+   8.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 5
+   9.   Normative References . . . . . . . . . . . . . . . . . . . . . 5
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
+        Intellectual Property and Copyright Statements . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guette & Courtay        Expires February 5, 2005                [Page 2]
+
+Internet-Draft      Automated Rollover Requirements          August 2004
+
+
+1.  Introduction
+
+   The DNS security extensions (DNSSEC) [4][8][7][9] uses public-key
+   cryptography and digital signatures.  It stores the public part of
+   keys in DNSKEY Resource Records (RRs).  Because old keys and
+   frequently used keys are vulnerable, they must be renewed
+   periodically.  In DNSSEC, this is the case for Zone Signing Keys
+   (ZSKs) and Key Signing Keys (KSKs) [1][2].  Automation of key
+   rollover process is necessary for large zones because there are too
+   many changes to handle a manual administration.
+
+   Let us consider for example a zone with 100000 secure delegations.
+   If the child zones change their keys once a year on average, that
+   implies 300 changes per day for the parent zone.  This amount of
+   changes are hard to manage manually.
+
+   Automated rollover is optional and resulting from an agreement
+   between the administrator of the parent zone and the administrator of
+   the child zone.  Of course, key rollover can also be done manually by
+   administrators.
+
+   This document describes the requirements for the design of messages
+   of automated key rollover process and focusses on interaction between
+   parent and child zone.
+
+2.  The Key Rollover Process
+
+   Key rollover consists in renewing the DNSSEC keys used to sign
+   resource records in a given DNS zone file.  There are two types of
+   rollover, ZSK rollovers and KSK rollovers.
+
+   In a ZSK rollover, all changes are local to the zone that renews its
+   key: there is no need to contact other zones (e.g., parent zone) to
+   propagate the performed changes because a ZSK has no associated DS
+   record in the parent zone.
+
+   In a KSK rollover, new DS RR(s) must be created and stored in the
+   parent zone.  In consequence, the child zone must contact its parent
+   zone and must notify it about the KSK change(s).
+
+   Manual key rollover exists and works [3].  The key rollover is built
+   from two parts of different nature:
+   o  An algorithm that generates new keys and signs the zone file.  It
+      could be local to the zone
+   o  The interaction between parent and child zones
+
+   One example of manual key rollover is:
+
+
+
+
+Guette & Courtay        Expires February 5, 2005                [Page 3]
+
+Internet-Draft      Automated Rollover Requirements          August 2004
+
+
+   o  The child zone creates a new KSK
+   o  The child zone waits for the creation of the DS RR in its parent
+      zone
+   o  The child zone deletes the old key.
+
+   In manual rollover, communications are managed by the zone
+   administrators and the security of these communications is out of
+   scope of DNSSEC.
+
+   Automated key rollover should use a secure communication between
+   parent and child zones.  This document concentrates on defining
+   interactions between entities present in key rollover process.
+
+3.  Basic Requirements
+
+   The main constraint to respect during a key rollover is that the
+   chain of trust MUST be preserved, even if a resolver retrieves some
+   RRs from recursive cache server.  Every RR MUST be verifiable at any
+   time, every RRs exchanged during the rollover should be authenticated
+   and their integrity should be guaranteed.
+
+   Two entities act during a KSK rollover: the child zone and its parent
+   zone.  These zones are generally managed by different administrators.
+   These administrators should agree on some parameters like
+   availability of automated rollover, the maximum delay between
+   notification of changes in the child zone and the resigning of the
+   parent zone.  The child zone needs to know this delay to schedule its
+   changes.
+
+4.  Messages authentication and information exchanged
+
+   Every exchanged message MUST be authenticated and the authentication
+   tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC
+   request with verifiable SIG records.
+
+   Once the changes related to a KSK are made in a child zone, this zone
+   MUST notify its parent zone in order to create the new DS RR and
+   store this DS RR in parent zone file.
+
+   The parent zone MUST receive all the child keys that needs the
+   creation of associated DS RRs in the parent zone.
+
+   Some errors could occur during transmission between child zone and
+   parent zone.  Key rollover solution MUST be fault tolerant, i.e.  at
+   any time the rollover MUST be in a consistent state and all RRs MUST
+   be verifiable, even if an error occurs.  That is to say that it MUST
+   remain a valid chain of trust.
+
+
+
+
+Guette & Courtay        Expires February 5, 2005                [Page 4]
+
+Internet-Draft      Automated Rollover Requirements          August 2004
+
+
+5.  Emergency Rollover
+
+   A key of a zone might be compromised and this key MUST be changed as
+   soon as possible.  Fast changes could break the chain of trust.  The
+   part of DNS tree having this zone as apex can become unverifiable,
+   but the break of the chain of trust is necessary if we want to no one
+   can use the compromised key to spoof DNS data.
+
+   In case of emergency rollover, the administrators of parent and child
+   zones should create new key(s) and DS RR(s) as fast as possible in
+   order to reduce the time the chain of trust is broken.
+
+6.  Other Resource Record concerned by automatic rollover
+
+   NS records are also present at delegation point, so when the child
+   zone renews some NS RR, the corresponding records at delegation point
+   in parent zone (glue) MUST be updated.  NS records are concerned by
+   rollover and this rollover could be automated too.  In this case,
+   when the child zone notifies its parent zone that some NS records
+   have been changed, the parent zone MUST verify that these NS records
+   are present in child zone before doing any changes in its own zone
+   file.  This allows to avoid inconsistency between NS records at
+   delegation point and NS records present in the child zone.
+
+7.  Security consideration
+
+   This document describes requirements to design an automated key
+   rollover in DNSSEC based on DNSSEC security.  In the same way, as
+   plain DNSSEC, the automatic key rollover contains no mechanism
+   protecting against denial of service (DoS).  The security level
+   obtain after an automatic key rollover, is the security level
+   provided by DNSSEC.
+
+8.  Acknowledgments
+
+   The authors want to acknowledge Francis Dupont, Mohsen Souissi,
+   Bernard Cousin, Bertrand L‰onard and members of IDsA project for
+   their contribution to this document.
+
+9  Normative References
+
+   [1]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+        RFC 3658, December 2003.
+
+   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
+        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+        RFC 3757, May 2004.
+
+
+
+
+Guette & Courtay        Expires February 5, 2005                [Page 5]
+
+Internet-Draft      Automated Rollover Requirements          August 2004
+
+
+   [3]  Kolkman, O., "DNSSEC Operational Practices",
+        draft-ietf-dnsop-dnssec-operational-practice-01 (work in
+        progress), May 2004.
+
+   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [5]  Eastlake, D., "DNS Request and Transaction Signatures (
+        SIG(0)s)", RFC 2931, September 2000.
+
+   [6]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+        "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+        2845, May 2000.
+
+   [7]  Arends, R., "Resource Records for the DNS Security Extensions",
+        draft-ietf-dnsext-dnssec-records-09 (work in progress), July
+        2004.
+
+   [8]  Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
+        "DNS Security Introduction and Requirements",
+        draft-ietf-dnsext-dnssec-intro-11 (work in progress), July 2004.
+
+   [9]  Arends, R., "Protocol Modifications for the DNS Security
+        Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in
+        progress), July 2004.
+
+
+Authors' Addresses
+
+   Gilles Guette
+   IRISA / INRIA
+   Campus de Beaulieu
+   35042  Rennes CEDEX
+   FR
+
+   EMail: gilles.guette@irisa.fr
+   URI:   http://www.irisa.fr
+
+
+   Olivier Courtay
+   Thomson R&D
+   1, avenue Belle Fontaine
+   35510  Cesson S‰vign‰ CEDEX
+   FR
+
+   EMail: olivier.courtay@thomson.net
+
+
+
+
+
+Guette & Courtay        Expires February 5, 2005                [Page 6]
+
+Internet-Draft      Automated Rollover Requirements          August 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Guette & Courtay        Expires February 5, 2005                [Page 7]
+
diff --git a/doc/draft/draft-ietf-dnsop-respsize-01.txt b/doc/draft/draft-ietf-dnsop-respsize-01.txt
new file mode 100644
index 00000000..f6ece882
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-respsize-01.txt
@@ -0,0 +1,485 @@
+   DNSOP Working Group                               Paul Vixie, ISC (Ed.)
+   INTERNET-DRAFT                                         Akira Kato, WIDE
+   <draft-ietf-dnsop-respsize-01.txt>                           July, 2004
+
+
+                           DNS Response Size Issues
+
+
+   Status of this Memo
+      This document is an Internet-Draft and is subject to all provisions
+      of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+      author represents that any applicable patent or other IPR claims of
+      which we are aware have been or will be disclosed, and any of which
+      we become aware will be disclosed, in accordance with RFC 3668.
+
+
+      Internet-Drafts are working documents of the Internet Engineering
+      Task Force (IETF), its areas, and its working groups.  Note that
+      other groups may also distribute working documents as Internet-
+      Drafts.
+
+
+      Internet-Drafts are draft documents valid for a maximum of six months
+      and may be updated, replaced, or obsoleted by other documents at any
+      time.  It is inappropriate to use Internet-Drafts as reference
+      material or to cite them other than as "work in progress."
+
+
+      The list of current Internet-Drafts can be accessed at
+      http://www.ietf.org/ietf/1id-abstracts.txt
+
+
+      The list of Internet-Draft Shadow Directories can be accessed at
+      http://www.ietf.org/shadow.html.
+
+
+   Copyright Notice
+
+
+      Copyright (C) The Internet Society (2003-2004).  All Rights Reserved.
+
+
+
+
+
+                                    Abstract
+
+
+      With a mandated default minimum maximum message size of 512 octets,
+      the DNS protocol presents some special problems for zones wishing to
+      expose a moderate or high number of authority servers (NS RRs).  This
+      document explains the operational issues caused by, or related to
+      this response size limit.
+
+
+
+
+
+
+   Expires December 2004                                           [Page 1]
+   INTERNET-DRAFT                  June 2003                       RESPSIZE
+
+
+
+   1 - Introduction and Overview
+
+
+   1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
+   octets.  Even though this limitation was due to the required minimum UDP
+   reassembly limit for IPv4, it is a hard DNS protocol limit and is not
+   implicitly relaxed by changes in transport, for example to IPv6.
+
+
+   1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
+   responses by mutual agreement of the requestor and responder.  However,
+   deployment of EDNS0 cannot be expected to reach every Internet resolver
+   in the short or medium term.  The 512 octet message size limit remains
+   in practical effect at this time.
+
+
+   1.3. Since DNS responses include a copy of the request, the space
+   available for response data is somewhat less than the full 512 octets.
+   For negative responses, there is rarely a space constraint.  For
+   positive and delegation responses, though, every octet must be carefully
+   and sparingly allocated.  This document specifically addresses
+   delegation response sizes.
+
+
+   2 - Delegation Details
+
+
+   2.1. A delegation response will include the following elements:
+
+
+      Header Section: fixed length (12 octets)
+      Question Section: original query (name, class, type)
+      Answer Section: (empty)
+      Authority Section: NS RRset (nameserver names)
+      Additional Section: A and AAAA RRsets (nameserver addresses)
+
+
+   2.2. If the total response size would exceed 512 octets, and if the data
+   that would not fit was in the question, answer, or authority section,
+   then the TC bit will be set (indicating truncation) which may cause the
+   requestor to retry using TCP, depending on what information was present
+   and what was omitted.  If a retry using TCP is needed, the total cost of
+   the transaction is much higher.
+
+
+   2.3. RRsets are never sent partially, so if truncation occurs, entire
+   RRsets are omitted.  Note that the authority section consists of a
+   single RRset.  It is absolutely essential that truncation not occur in
+   the authority section.
+
+
+
+
+
+
+
+
+   Expires December 2004                                           [Page 2]
+   INTERNET-DRAFT                  June 2003                       RESPSIZE
+
+
+
+   2.4. DNS label compression allows a domain name to be instantiated only
+   once per DNS message, and then referenced with a two-octet "pointer"
+   from other locations in that same DNS message.  If all nameserver names
+   in a message are similar (for example, all ending in ".ROOT-
+   SERVERS.NET"), then more space will be available for uncompressable data
+   (such as nameserver addresses).
+
+
+   2.5. The query name can be as long as 255 characters of presentation
+   data, which can be up to 256 octets of network data.  In this worst case
+   scenario, the question section will be 260 octets in size, which would
+   leave only 240 octets for the authority and additional sections (after
+   deducting 12 octets for the fixed length header.)
+
+
+   2.6. Average and maximum question section sizes can be predicted by the
+   zone owner, since they will know what names actually exist, and can
+   measure which ones are queried for most often.  For cost and performance
+   reasons, the majority of requests should be satisfied without truncation
+   or TCP retry.
+
+
+   2.7. Requestors who deliberately send large queries to force truncation
+   are only increasing their own costs, and cannot effectively attack the
+   resources of an authority server since the requestor would have to retry
+   using TCP to complete the attack.  An attack that always used TCP would
+   have a lower cost.
+
+
+   2.8. The minimum useful number of address records is two, since with
+   only one address, the probability that it would refer to an unreachable
+   server is too high.  Truncation which occurs after two address records
+   have been added to the additional data section is therefore less
+   operationally significant than truncation which occurs earlier.
+
+
+   2.9. The best case is no truncation.  (This is because many requestors
+   will retry using TCP by reflex, without considering whether the omitted
+   data was actually necessary.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+   Expires December 2004                                           [Page 3]
+   INTERNET-DRAFT                  June 2003                       RESPSIZE
+
+
+
+   3 - Analysis
+
+
+   3.1. An instrumented protocol trace of a best case delegation response
+   follows.  Note that 13 servers are named, and 13 addresses are given.
+   This query was artificially designed to exactly reach the 512 octet
+   limit.
+
+
+      ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
+      ;; QUERY SECTION:
+      ;;  [23456789.123456789.123456789.\
+           123456789.123456789.123456789.com A IN]        ;; @80
+
+
+      ;; AUTHORITY SECTION:
+      com.                 86400 NS  E.GTLD-SERVERS.NET.  ;; @112
+      com.                 86400 NS  F.GTLD-SERVERS.NET.  ;; @128
+      com.                 86400 NS  G.GTLD-SERVERS.NET.  ;; @144
+      com.                 86400 NS  H.GTLD-SERVERS.NET.  ;; @160
+      com.                 86400 NS  I.GTLD-SERVERS.NET.  ;; @176
+      com.                 86400 NS  J.GTLD-SERVERS.NET.  ;; @192
+      com.                 86400 NS  K.GTLD-SERVERS.NET.  ;; @208
+      com.                 86400 NS  L.GTLD-SERVERS.NET.  ;; @224
+      com.                 86400 NS  M.GTLD-SERVERS.NET.  ;; @240
+      com.                 86400 NS  A.GTLD-SERVERS.NET.  ;; @256
+      com.                 86400 NS  B.GTLD-SERVERS.NET.  ;; @272
+      com.                 86400 NS  C.GTLD-SERVERS.NET.  ;; @288
+      com.                 86400 NS  D.GTLD-SERVERS.NET.  ;; @304
+
+
+      ;; ADDITIONAL SECTION:
+      A.GTLD-SERVERS.NET.  86400 A   192.5.6.30           ;; @320
+      B.GTLD-SERVERS.NET.  86400 A   192.33.14.30         ;; @336
+      C.GTLD-SERVERS.NET.  86400 A   192.26.92.30         ;; @352
+      D.GTLD-SERVERS.NET.  86400 A   192.31.80.30         ;; @368
+      E.GTLD-SERVERS.NET.  86400 A   192.12.94.30         ;; @384
+      F.GTLD-SERVERS.NET.  86400 A   192.35.51.30         ;; @400
+      G.GTLD-SERVERS.NET.  86400 A   192.42.93.30         ;; @416
+      H.GTLD-SERVERS.NET.  86400 A   192.54.112.30        ;; @432
+      I.GTLD-SERVERS.NET.  86400 A   192.43.172.30        ;; @448
+      J.GTLD-SERVERS.NET.  86400 A   192.48.79.30         ;; @464
+      K.GTLD-SERVERS.NET.  86400 A   192.52.178.30        ;; @480
+      L.GTLD-SERVERS.NET.  86400 A   192.41.162.30        ;; @496
+      M.GTLD-SERVERS.NET.  86400 A   192.55.83.30         ;; @512
+
+
+      ;; MSG SIZE  sent: 80  rcvd: 512
+
+
+
+
+
+
+   Expires December 2004                                           [Page 4]
+   INTERNET-DRAFT                  June 2003                       RESPSIZE
+
+
+
+   3.2. For longer query names, the number of address records supplied will
+   be lower.  Furthermore, it is only by using a common parent name (which
+   is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
+   fit.  The following output from a response simulator demonstrates these
+   properties:
+
+
+      % perl respsize.pl 13 13 0
+        common name, average case: msg:303    nsaddr#13 (green)
+        common name,   worst case: msg:495    nsaddr# 1 (red)
+      uncommon name, average case: msg:457    nsaddr# 3 (orange)
+      uncommon name,   worst case: msg:649(*) nsaddr# 0 (red)
+      % perl respsize.pl 13 13 2
+        common name, average case: msg:303    nsaddr#11 (orange)
+        common name,   worst case: msg:495    nsaddr# 1 (red)
+      uncommon name, average case: msg:457    nsaddr# 2 (orange)
+      uncommon name,   worst case: msg:649(*) nsaddr# 0 (red)
+
+
+   (Note: The response simulator program is shown in Section 5.)
+
+
+   Here we use the term "green" if all address records could fit, or
+   "orange" if two or more could fit, or "red" if fewer than two could fit.
+   It's clear that without a common parent for nameserver names, much space
+   would be lost.
+
+
+   We're assuming an average query name size of 64 since that is the
+   typical average maximum size seen in trace data at the time of this
+   writing.  If Internationalized Domain Name (IDN) or any other technology
+   which results in larger query names be deployed significantly in advance
+   of EDNS, then more new measurements and new estimates will have to be
+   made.
+
+
+   4 - Conclusions
+
+
+   4.1. The current practice of giving all nameserver names a common parent
+   (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
+   responses and allows for more nameservers to be enumerated than would
+   otherwise be possible.  (Note that in this case it is wise to serve the
+   common parent domain's zone from the same servers that are named within
+   it, in order to limit external dependencies when all your eggs are in a
+   single basket.)
+
+
+   4.2. Thirteen (13) seems to be the effective maximum number of
+   nameserver names usable traditional (non-extended) DNS, assuming a
+   common parent domain name, and assuming that additional-data truncation
+   is undesirable in the average case.
+
+
+
+
+   Expires December 2004                                           [Page 5]
+   INTERNET-DRAFT                  June 2003                       RESPSIZE
+
+
+
+   4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
+   prototypical delegation that currently contains thirteen (13) IPv4
+   nameserver addresses (A RRs) for thirteen (13) nameserver names under a
+   common parent, would not have a significant negative operational impact
+   on the domain name system.
+
+
+   5 - Source Code
+
+
+   #!/usr/bin/perl -w
+
+
+   $asize = 2+2+2+4+2+4;
+   $aaaasize = 2+2+2+4+2+16;
+   ($nns, $na, $naaaa) = @ARGV;
+   test("common", "average", common_name_average($nns),
+        $na, $naaaa);
+   test("common", "worst", common_name_worst($nns),
+        $na, $naaaa);
+   test("uncommon", "average", uncommon_name_average($nns),
+        $na, $naaaa);
+   test("uncommon", "worst", uncommon_name_worst($nns),
+        $na, $naaaa);
+   exit 0;
+
+
+   sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_;
+        my $nglue = numglue($msg, $na, $naaaa);
+        printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n",
+             $namekind, $casekind,
+             $msg, ($msg > 512) ? "(*)" : "   ",
+             $nglue, ($nglue == $na + $naaaa) ? "green"
+                  : ($nglue >= 2) ? "orange"
+                       : "red";
+   }
+
+
+   sub pnum { my ($num, $tot) = @_;
+        return sprintf "%3d%s",
+   }
+
+
+   sub numglue { my ($msg, $na, $naaaa) = @_;
+        my $space = ($msg > 512) ? 0 : (512 - $msg);
+        my $num = 0;
+
+
+        while ($space && ($na || $naaaa )) {
+             if ($na) {
+                  if ($space >= $asize) {
+                       $space -= $asize;
+
+
+
+
+   Expires December 2004                                           [Page 6]
+   INTERNET-DRAFT                  June 2003                       RESPSIZE
+
+
+
+                       $num++;
+                  }
+                  $na--;
+             }
+             if ($naaaa) {
+                  if ($space >= $aaaasize) {
+                       $space -= $aaaasize;
+                       $num++;
+                  }
+                  $naaaa--;
+             }
+        }
+        return $num;
+   }
+
+
+   sub msgsize { my ($qname, $nns, $nsns) = @_;
+        return  12 +                            # header
+                $qname+2+2 +                    # query
+                0 +                             # answer
+                $nns * (4+2+2+4+2+$nsns);       # authority
+   }
+
+
+   sub average_case { my ($nns, $nsns) = @_;
+        return msgsize(64, $nns, $nsns);
+   }
+
+
+   sub worst_case { my ($nns, $nsns) = @_;
+        return msgsize(256, $nns, $nsns);
+   }
+
+
+   sub common_name_average { my ($nns) = @_;
+        return 15 + average_case($nns, 2);
+   }
+
+
+   sub common_name_worst { my ($nns) = @_;
+        return 15 + worst_case($nns, 2);
+   }
+
+
+   sub uncommon_name_average { my ($nns) = @_;
+        return average_case($nns, 15);
+   }
+
+
+   sub uncommon_name_worst { my ($nns) = @_;
+        return worst_case($nns, 15);
+   }
+
+
+
+
+   Expires December 2004                                           [Page 7]
+   INTERNET-DRAFT                  June 2003                       RESPSIZE
+
+
+
+   Security Considerations
+
+
+   The recommendations contained in this document have no known security
+   implications.
+
+
+   IANA Considerations
+
+
+   This document does not call for changes or additions to any IANA
+   registry.
+
+
+   IPR Statement
+
+
+   Copyright (C) The Internet Society (2003-2004).  This document is
+   subject to the rights, licenses and restrictions contained in BCP 78,
+   and except as set forth therein, the authors retain all their rights.
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
+   IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+   Authors' Addresses
+
+
+   Paul Vixie
+      950 Charter Street
+      Redwood City, CA 94063
+      +1 650 423 1301
+      vixie@isc.org
+
+
+   Akira Kato
+      University of Tokyo, Information Technology Center
+      2-11-16 Yayoi Bunkyo
+      Tokyo 113-8658, JAPAN
+      +81 3 5841 2750
+      kato@wide.ad.jp
+
+
+
+
+
+
+
+
+
+
+   Expires December 2004                                           [Page 8] 
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsop-serverid-02.txt b/doc/draft/draft-ietf-dnsop-serverid-02.txt
new file mode 100644
index 00000000..b593c571
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-serverid-02.txt
@@ -0,0 +1,617 @@
+
+
+Network Working Group                                           S. Woolf
+Internet-Draft                         Internet Systems Consortium, Inc.
+Expires: January 16, 2005                                      D. Conrad
+                                                           Nominum, Inc.
+                                                           July 18, 2004
+
+
+               Identifying an Authoritative Name `Server
+                      draft-ietf-dnsop-serverid-02
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 16, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.  A standardized mechanism to
+   determine the identity of a name server responding to a particular
+   query would be useful, particularly as a diagnostic aid.  Existing ad
+
+
+
+Woolf & Conrad          Expires January 16, 2005                [Page 1]
+
+Internet-Draft    Identifying an Authoritative Name `Server    July 2004
+
+
+   hoc mechanisms for addressing this concern are not adequate.  This
+   document attempts to describe the common ad hoc solution to this
+   problem, including its advantages and disadvantasges, and to
+   characterize an improved mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires January 16, 2005                [Page 2]
+
+Internet-Draft    Identifying an Authoritative Name `Server    July 2004
+
+
+1.  Introduction
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.  A standardized mechanism to
+   determine the identity of a name server responding to a particular
+   query would be useful, particularly as a diagnostic aid.
+
+   Unfortunately, existing ad-hoc mechanisms for providing such
+   identification have some shortcomings, not the least of which is the
+   lack of prior analysis of exactly how such a mechanism should be
+   designed and deployed.  This document describes the existing
+   convention used in one widely deployed implementation of the DNS
+   protocol and discusses requirements for an improved solution to the
+   problem.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires January 16, 2005                [Page 3]
+
+Internet-Draft    Identifying an Authoritative Name `Server    July 2004
+
+
+2.  Rationale
+
+   Identifying which name server is responding to queries is often
+   useful, particularly in attempting to diagnose name server
+   difficulties.  However, relying on the IP address of the name server
+   has become more problematic due the deployment of various load
+   balancing solutions, including the use of shared unicast addresses as
+   documented in [RFC3258].
+
+   An unfortunate side effect of these load balancing solutions is that
+   traditional methods of determining which server is responding can be
+   unreliable.  Specifically, non-DNS methods such as ICMP ping, TCP
+   connections, or non-DNS UDP packets (e.g., as generated by tools such
+   as "traceroute"), etc., can end up going to a different server than
+   that which receives the DNS queries.
+
+   The widespread use of the existing convention suggests a need for a
+   documented, interoperable means of querying the identity of a
+   nameserver that may be part of an anycast or load-balancing cluster.
+   At the same time, however, it also has some drawbacks that argue
+   against standardizing it as it's been practiced so far.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires January 16, 2005                [Page 4]
+
+Internet-Draft    Identifying an Authoritative Name `Server    July 2004
+
+
+3.  Existing Conventions
+
+   Recent versions of the commonly deployed Berkeley Internet Name
+   Domain implementation of the DNS protocol suite from the Internet
+   Software Consortium [BIND] support a way of identifying a particular
+   server via the use of a standard, if somewhat unusual, DNS query.
+   Specifically, a query to a late model BIND server for a TXT resource
+   record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
+   return a string that can be configured by the name server
+   administrator to provide a unique identifier for the responding
+   server (defaulting to the value of a gethostname() call).  This
+   mechanism, which is an extension of the BIND convention of using
+   CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
+   version information, has been copied by several name server vendors.
+
+   For reference, the other well-known name used by recent versions of
+   BIND within the CHAOS class "BIND." domain is "VERSION.BIND."  A
+   query for a TXT RR for this name will return an administratively re-
+   definable string which defaults to the version of the server
+   responding.
+
+3.1  Advantages
+
+   There are several valuable attributes to this mechanism, which
+   account for its usefulness.
+   1.  This mechanism is within the DNS protocol itself.  An
+       identification mechanism that relies on the DNS protocol is more
+       likely to be successful (although not guaranteed) in going to the
+       same machine as a "normal" DNS query.
+   2.  It is simple to configure.  An administrator can easily turn on
+       this feature and control the results of the relevant query.
+   3.  It allows the administrator complete control of what information
+       is given out in the response, minimizing passive leakage of
+       implementation or configuration details.  Such details are often
+       considered sensitive by infrastructure operators.
+
+3.2  Disadvantages
+
+   At the same time, there are some forbidding drawbacks to the
+   VERSION.BIND mechanism that argue against standardizing it as it
+   currently operates.
+   1.  It requires an additional query to correlate between the answer
+       to a DNS query under normal conditions and the supposed identity
+       of the server receiving the query.  There are a number of
+       situations in which this simply isn't reliable.
+   2.  It reserves an entire class in the DNS (CHAOS) for what amounts
+       to one zone.  While CHAOS class is defined in [RFC1034] and
+       [RFC1035], it's not clear that supporting it solely for this
+
+
+
+Woolf & Conrad          Expires January 16, 2005                [Page 5]
+
+Internet-Draft    Identifying an Authoritative Name `Server    July 2004
+
+
+       purpose is a good use of the namespace or of implementation
+       effort.
+   3.  It is implementation specific.  BIND is one DNS implementation.
+       At the time of this writing, it is probably the most prevalent,
+       for authoritative servers anyway.  This does not justify
+       standardizing on its ad hoc solution to a problem shared across
+       many operators and implementors.
+
+   The first of the listed disadvantages is technically the most
+   serious.  It argues for an attempt to design a good answer to the
+   problem that "I need to know what nameserver is answering my
+   queries", not simply a convenient one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires January 16, 2005                [Page 6]
+
+Internet-Draft    Identifying an Authoritative Name `Server    July 2004
+
+
+4.  Characteristics of an Implementation Neutral Convention
+
+   The discussion above of advantages and disadvantages to the
+   HOSTNAME.BIND mechanism suggest some requirements for a better
+   solution to the server identification problem.  These are summarized
+   here as guidelines for any effort to provide appropriate protocol
+   extensions:
+   1.  The mechanism adopted MUST be in-band for the DNS protocol.  That
+       is, it needs to allow the query for the server's identifying
+       information to be part of a normal, operational query.  It SHOULD
+       also permit a separate, dedicated query for the server's
+       identifying information.
+   2.  The new mechanism should not require dedicated namespaces or
+       other reserved values outside of the existing protocol mechanisms
+       for these, i.e.  the OPT pseudo-RR.
+   3.  Support for the identification functionality SHOULD be easy to
+       implement and easy to enable.  It MUST be easy to disable and
+       SHOULD lend itself to access controls on who can query for it.
+   4.  It should be possible to return a unique identifier for a server
+       without requiring the exposure of information that may be
+       non-public and considered sensitive by the operator, such as a
+       hostname or unicast IP address maintained for administrative
+       purposes.
+   5.  The identification mechanism SHOULD NOT be
+       implementation-specific.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires January 16, 2005                [Page 7]
+
+Internet-Draft    Identifying an Authoritative Name `Server    July 2004
+
+
+5.  IANA Considerations
+
+   This document proposes no specific IANA action.  Protocol extensions,
+   if any, to meet the requirements described are out of scope for this
+   document.  Should such extensions be specified and adopted by normal
+   IETF process, the specification will include appropriate guidance to
+   IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires January 16, 2005                [Page 8]
+
+Internet-Draft    Identifying an Authoritative Name `Server    July 2004
+
+
+6.  Security Considerations
+
+   Providing identifying information as to which server is responding
+   can be seen as information leakage and thus a security risk.  This
+   motivates the suggestion above that a new mechanism for server
+   identification allow the administrator to disable the functionality
+   altogether or partially restrict availability of the data.  It also
+   suggests that the serverid data should not be readily correlated with
+   a hostname or unicast IP address that may be considered private to
+   the nameserver operator's management infrastructure.
+
+   Propagation of protocol or service meta-data can sometimes expose the
+   application to denial of service or other attack.  As DNS is a
+   critically important infrastructure service for the production
+   Internet, extra care needs to be taken against this risk for
+   designers, implementors, and operators of a new mechanism for server
+   identification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires January 16, 2005                [Page 9]
+
+Internet-Draft    Identifying an Authoritative Name `Server    July 2004
+
+
+7.  Acknowledgements
+
+   The technique for host identification documented here was initially
+   implemented by Paul Vixie of the Internet Software Consortium in the
+   Berkeley Internet Name Daemon package.  Comments and questions on
+   earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
+   Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
+   ICANN Root Server System Advisory Committee.  The newest draft takes
+   a significantly different direction from previous versions, owing to
+   discussion among contributors to the DNSOP working group and others,
+   particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler,
+   and Rob Austein.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires January 16, 2005               [Page 10]
+
+Internet-Draft    Identifying an Authoritative Name `Server    July 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Woolf & Conrad          Expires January 16, 2005               [Page 11]
+
+
diff --git a/lib/bind/Makefile.in b/lib/bind/Makefile.in
index 7b672e8f..3f24ba2f 100644
--- a/lib/bind/Makefile.in
+++ b/lib/bind/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.12.2.9 2004/03/09 09:17:23 marka Exp $
+# $Id: Makefile.in,v 1.12.2.10 2004/07/20 07:00:18 marka Exp $
 
 srcdir =        @srcdir@
 VPATH =         @srcdir@
@@ -100,7 +100,7 @@ libbind.@SA@: ${OBJS}
 
 libbind.la: ${OBJS}
 	${LIBTOOL_MODE_LINK} \
-	${CC} ${ALL_CFLAGS} -o libbind.la -rpath ${libdir} \
+	${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libbind.la -rpath ${libdir} \
 		-version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \
 		${OBJS} ${LIBS}
 
diff --git a/lib/bind/api b/lib/bind/api
index 0d0496c8..0ca3d9e7 100644
--- a/lib/bind/api
+++ b/lib/bind/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 3
-LIBREVISION = 5
+LIBREVISION = 6
 LIBAGE = 0
diff --git a/lib/bind/configure b/lib/bind/configure
index b89a875a..30aa7520 100755
--- a/lib/bind/configure
+++ b/lib/bind/configure
@@ -1,5 +1,5 @@
 #! /bin/sh
-# From configure.in Revision: 1.83.2.6 .
+# From configure.in Revision: 1.83.2.8 .
 # Guess values for system-dependent variables and create Makefiles.
 # Generated by GNU Autoconf 2.59.
 #
@@ -464,7 +464,7 @@ ac_includes_default="\
 # include <unistd.h>
 #endif"
 
-ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_NEEDSYSSELECTH WANT_IRS_GR WANT_IRS_GR_OBJS WANT_IRS_PW WANT_IRS_PW_OBJS WANT_IRS_NIS WANT_IRS_NIS_OBJS WANT_IRS_NISGR_OBJS WANT_IRS_NISPW_OBJS WANT_IRS_DBPW_OBJS ALWAYS_DEFINES DO_PTHREADS WANT_IRS_THREADSGR_OBJS WANT_IRS_THREADSPW_OBJS WANT_IRS_THREADS_OBJS ISC_THREAD_DIR DAEMON_OBJS NEED_DAEMON STRSEP_OBJS NEED_STRSEP NEED_STRERROR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK HAS_INET6_STRUCTS ISC_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H HAS_IN_ADDR6 NEED_IN6ADDR_ANY ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C HAVE_SIN6_SCOPE_ID HAVE_SOCKADDR_STORAGE ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON HAVE_SA_LEN HAVE_MINIMUM_IFREQ BSD_COMP SOLARIS_BITTYPES USE_FIONBIO_IOCTL PORT_DIR PORT_INCLUDE ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO NEED_PSELECT NEED_GETTIMEOFDAY HAVE_STRNDUP ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS USE_SYSERROR_LIST ISC_PLATFORM_QUADFORMAT ISC_SOCKLEN_T GETGROUPLIST_ARGS NET_R_ARGS NET_R_BAD NET_R_COPY NET_R_COPY_ARGS NET_R_OK NET_R_SETANSWER NET_R_RETURN GETNETBYADDR_ADDR_T NETENT_DATA NET_R_ENT_ARGS NET_R_SET_RESULT NET_R_SET_RETURN NET_R_END_RESULT NET_R_END_RETURN GROUP_R_ARGS GROUP_R_BAD GROUP_R_OK GROUP_R_RETURN GROUP_R_END_RESULT GROUP_R_END_RETURN GROUP_R_ENT_ARGS GROUP_R_SET_RESULT GROUP_R_SET_RETURN HOST_R_ARGS HOST_R_BAD HOST_R_COPY HOST_R_COPY_ARGS HOST_R_ERRNO HOST_R_OK HOST_R_RETURN HOST_R_SETANSWER HOSTENT_DATA HOST_R_END_RESULT HOST_R_END_RETURN HOST_R_ENT_ARGS HOST_R_SET_RESULT HOST_R_SET_RETURN SETPWENT_VOID SETGRENT_VOID NGR_R_ARGS NGR_R_BAD NGR_R_COPY NGR_R_COPY_ARGS NGR_R_OK NGR_R_RETURN NGR_R_PRIVATE NGR_R_END_RESULT NGR_R_END_RETURN NGR_R_ENT_ARGS NGR_R_SET_RESULT NGR_R_SET_RETURN PROTO_R_ARGS PROTO_R_BAD PROTO_R_COPY PROTO_R_COPY_ARGS PROTO_R_OK PROTO_R_SETANSWER PROTO_R_RETURN PROTO_R_END_RESULT PROTO_R_END_RETURN PROTO_R_ENT_ARGS PROTO_R_SET_RESULT PROTO_R_SET_RETURN PASS_R_ARGS PASS_R_BAD PASS_R_COPY PASS_R_COPY_ARGS PASS_R_OK PASS_R_RETURN PASS_R_END_RESULT PASS_R_END_RETURN PASS_R_ENT_ARGS PASS_R_SET_RESULT PASS_R_SET_RETURN SERV_R_ARGS SERV_R_BAD SERV_R_COPY SERV_R_COPY_ARGS SERV_R_OK SERV_R_SETANSWER SERV_R_RETURN SERV_R_END_RESULT SERV_R_END_RETURN SERV_R_ENT_ARGS SERV_R_SET_RESULT SERV_R_SET_RETURN SETNETGRENT_ARGS INNETGR_ARGS ISC_PLATFORM_BRACEPTHREADONCEINIT BIND9_TOP_BUILDDIR BIND9_VERSION LIBOBJS LTLIBOBJS'
+ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build build_cpu build_vendor build_os host host_cpu host_vendor host_os SET_MAKE RANLIB ac_ct_RANLIB INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA STD_CINCLUDES STD_CDEFINES STD_CWARNINGS CCOPT AR ARFLAGS LN ETAGS PERL CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP EGREP ISC_PLATFORM_NEEDSYSSELECTH WANT_IRS_GR WANT_IRS_GR_OBJS WANT_IRS_PW WANT_IRS_PW_OBJS WANT_IRS_NIS WANT_IRS_NIS_OBJS WANT_IRS_NISGR_OBJS WANT_IRS_NISPW_OBJS WANT_IRS_DBPW_OBJS ALWAYS_DEFINES DO_PTHREADS WANT_IRS_THREADSGR_OBJS WANT_IRS_THREADSPW_OBJS WANT_IRS_THREADS_OBJS USE_IFNAMELINKID ISC_THREAD_DIR DAEMON_OBJS NEED_DAEMON STRSEP_OBJS NEED_STRSEP NEED_STRERROR MKDEPCC MKDEPCFLAGS MKDEPPROG IRIX_DNSSEC_WARNINGS_HACK purify_path PURIFY LN_S ECHO ac_ct_AR STRIP ac_ct_STRIP CXX CXXFLAGS ac_ct_CXX CXXCPP F77 FFLAGS ac_ct_F77 LIBTOOL O A SA LIBTOOL_MKDEP_SED LIBTOOL_MODE_COMPILE LIBTOOL_MODE_INSTALL LIBTOOL_MODE_LINK HAS_INET6_STRUCTS ISC_PLATFORM_NEEDNETINETIN6H ISC_PLATFORM_NEEDNETINET6IN6H HAS_IN_ADDR6 NEED_IN6ADDR_ANY ISC_PLATFORM_HAVEIN6PKTINFO ISC_PLATFORM_FIXIN6ISADDR ISC_IPV6_H ISC_IPV6_O ISC_ISCIPV6_O ISC_IPV6_C HAVE_SIN6_SCOPE_ID HAVE_SOCKADDR_STORAGE ISC_PLATFORM_NEEDNTOP ISC_PLATFORM_NEEDPTON ISC_PLATFORM_NEEDATON HAVE_SA_LEN HAVE_MINIMUM_IFREQ BSD_COMP SOLARIS_BITTYPES USE_FIONBIO_IOCTL PORT_DIR PORT_INCLUDE ISC_PLATFORM_MSGHDRFLAVOR ISC_PLATFORM_NEEDPORTT ISC_LWRES_ENDHOSTENTINT ISC_LWRES_SETNETENTINT ISC_LWRES_ENDNETENTINT ISC_LWRES_GETHOSTBYADDRVOID ISC_LWRES_NEEDHERRNO ISC_LWRES_GETIPNODEPROTO ISC_LWRES_GETADDRINFOPROTO ISC_LWRES_GETNAMEINFOPROTO NEED_PSELECT NEED_GETTIMEOFDAY HAVE_STRNDUP ISC_PLATFORM_NEEDSTRSEP ISC_PLATFORM_NEEDVSNPRINTF ISC_EXTRA_OBJS ISC_EXTRA_SRCS USE_SYSERROR_LIST ISC_PLATFORM_QUADFORMAT ISC_SOCKLEN_T GETGROUPLIST_ARGS NET_R_ARGS NET_R_BAD NET_R_COPY NET_R_COPY_ARGS NET_R_OK NET_R_SETANSWER NET_R_RETURN GETNETBYADDR_ADDR_T NETENT_DATA NET_R_ENT_ARGS NET_R_SET_RESULT NET_R_SET_RETURN NET_R_END_RESULT NET_R_END_RETURN GROUP_R_ARGS GROUP_R_BAD GROUP_R_OK GROUP_R_RETURN GROUP_R_END_RESULT GROUP_R_END_RETURN GROUP_R_ENT_ARGS GROUP_R_SET_RESULT GROUP_R_SET_RETURN HOST_R_ARGS HOST_R_BAD HOST_R_COPY HOST_R_COPY_ARGS HOST_R_ERRNO HOST_R_OK HOST_R_RETURN HOST_R_SETANSWER HOSTENT_DATA HOST_R_END_RESULT HOST_R_END_RETURN HOST_R_ENT_ARGS HOST_R_SET_RESULT HOST_R_SET_RETURN SETPWENT_VOID SETGRENT_VOID NGR_R_ARGS NGR_R_BAD NGR_R_COPY NGR_R_COPY_ARGS NGR_R_OK NGR_R_RETURN NGR_R_PRIVATE NGR_R_END_RESULT NGR_R_END_RETURN NGR_R_ENT_ARGS NGR_R_SET_RESULT NGR_R_SET_RETURN PROTO_R_ARGS PROTO_R_BAD PROTO_R_COPY PROTO_R_COPY_ARGS PROTO_R_OK PROTO_R_SETANSWER PROTO_R_RETURN PROTO_R_END_RESULT PROTO_R_END_RETURN PROTO_R_ENT_ARGS PROTO_R_SET_RESULT PROTO_R_SET_RETURN PASS_R_ARGS PASS_R_BAD PASS_R_COPY PASS_R_COPY_ARGS PASS_R_OK PASS_R_RETURN PASS_R_END_RESULT PASS_R_END_RETURN PASS_R_ENT_ARGS PASS_R_SET_RESULT PASS_R_SET_RETURN SERV_R_ARGS SERV_R_BAD SERV_R_COPY SERV_R_COPY_ARGS SERV_R_OK SERV_R_SETANSWER SERV_R_RETURN SERV_R_END_RESULT SERV_R_END_RETURN SERV_R_ENT_ARGS SERV_R_SET_RESULT SERV_R_SET_RETURN SETNETGRENT_ARGS INNETGR_ARGS ISC_PLATFORM_BRACEPTHREADONCEINIT BIND9_TOP_BUILDDIR BIND9_VERSION LIBOBJS LTLIBOBJS'
 ac_subst_files='BIND9_INCLUDES BIND9_MAKE_RULES LIBBIND_API'
 
 # Initialize some variables set by options.
@@ -5716,6 +5716,104 @@ fi
 
 
 
+echo "$as_me:$LINENO: checking for if_nametoindex" >&5
+echo $ECHO_N "checking for if_nametoindex... $ECHO_C" >&6
+if test "${ac_cv_func_if_nametoindex+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+/* Define if_nametoindex to an innocuous variant, in case <limits.h> declares if_nametoindex.
+   For example, HP-UX 11i <limits.h> declares gettimeofday.  */
+#define if_nametoindex innocuous_if_nametoindex
+
+/* System header to define __stub macros and hopefully few prototypes,
+    which can conflict with char if_nametoindex (); below.
+    Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
+    <limits.h> exists even on freestanding compilers.  */
+
+#ifdef __STDC__
+# include <limits.h>
+#else
+# include <assert.h>
+#endif
+
+#undef if_nametoindex
+
+/* Override any gcc2 internal prototype to avoid an error.  */
+#ifdef __cplusplus
+extern "C"
+{
+#endif
+/* We use char because int might match the return type of a gcc2
+   builtin and then its argument prototype would still apply.  */
+char if_nametoindex ();
+/* The GNU C library defines this for functions which it implements
+    to always fail with ENOSYS.  Some functions are actually named
+    something starting with __ and the normal name is an alias.  */
+#if defined (__stub_if_nametoindex) || defined (__stub___if_nametoindex)
+choke me
+#else
+char (*f) () = if_nametoindex;
+#endif
+#ifdef __cplusplus
+}
+#endif
+
+int
+main ()
+{
+return f != if_nametoindex;
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"
+			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_func_if_nametoindex=yes
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_cv_func_if_nametoindex=no
+fi
+rm -f conftest.err conftest.$ac_objext \
+      conftest$ac_exeext conftest.$ac_ext
+fi
+echo "$as_me:$LINENO: result: $ac_cv_func_if_nametoindex" >&5
+echo "${ECHO_T}$ac_cv_func_if_nametoindex" >&6
+if test $ac_cv_func_if_nametoindex = yes; then
+  USE_IFNAMELINKID="#define USE_IFNAMELINKID 1"
+else
+  USE_IFNAMELINKID="#undef USE_IFNAMELINKID"
+fi
+
+
+
 ISC_THREAD_DIR=$thread_dir
 
 
@@ -7197,7 +7295,7 @@ ia64-*-hpux*)
   ;;
 *-*-irix6*)
   # Find out which ABI we are using.
-  echo '#line 7200 "configure"' > conftest.$ac_ext
+  echo '#line 7298 "configure"' > conftest.$ac_ext
   if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
   (eval $ac_compile) 2>&5
   ac_status=$?
@@ -8187,7 +8285,7 @@ fi
 
 
 # Provide some information about the compiler.
-echo "$as_me:8190:" \
+echo "$as_me:8288:" \
      "checking for Fortran 77 compiler version" >&5
 ac_compiler=`set X $ac_compile; echo $2`
 { (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5
@@ -9225,11 +9323,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:9228: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:9326: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:9232: \$? = $ac_status" >&5
+   echo "$as_me:9330: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -9458,11 +9556,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:9461: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:9559: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:9465: \$? = $ac_status" >&5
+   echo "$as_me:9563: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -9518,11 +9616,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:9521: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:9619: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:9525: \$? = $ac_status" >&5
+   echo "$as_me:9623: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -11702,7 +11800,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 11705 "configure"
+#line 11803 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11800,7 +11898,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 11803 "configure"
+#line 11901 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -13983,11 +14081,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:13986: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:14084: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:13990: \$? = $ac_status" >&5
+   echo "$as_me:14088: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -14043,11 +14141,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:14046: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:14144: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:14050: \$? = $ac_status" >&5
+   echo "$as_me:14148: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -15404,7 +15502,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 15407 "configure"
+#line 15505 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -15502,7 +15600,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 15505 "configure"
+#line 15603 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -16329,11 +16427,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:16332: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:16430: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:16336: \$? = $ac_status" >&5
+   echo "$as_me:16434: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -16389,11 +16487,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:16392: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:16490: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:16396: \$? = $ac_status" >&5
+   echo "$as_me:16494: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -18427,11 +18525,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:18430: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:18528: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:18434: \$? = $ac_status" >&5
+   echo "$as_me:18532: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -18660,11 +18758,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:18663: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:18761: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>conftest.err)
    ac_status=$?
    cat conftest.err >&5
-   echo "$as_me:18667: \$? = $ac_status" >&5
+   echo "$as_me:18765: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s "$ac_outfile"; then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
@@ -18720,11 +18818,11 @@ else
    -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
    -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
-   (eval echo "\"\$as_me:18723: $lt_compile\"" >&5)
+   (eval echo "\"\$as_me:18821: $lt_compile\"" >&5)
    (eval "$lt_compile" 2>out/conftest.err)
    ac_status=$?
    cat out/conftest.err >&5
-   echo "$as_me:18727: \$? = $ac_status" >&5
+   echo "$as_me:18825: \$? = $ac_status" >&5
    if (exit $ac_status) && test -s out/conftest2.$ac_objext
    then
      # The compiler can only warn and ignore the option if not recognized
@@ -20904,7 +21002,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 20907 "configure"
+#line 21005 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -21002,7 +21100,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<EOF
-#line 21005 "configure"
+#line 21103 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -31057,6 +31155,7 @@ s,@DO_PTHREADS@,$DO_PTHREADS,;t t
 s,@WANT_IRS_THREADSGR_OBJS@,$WANT_IRS_THREADSGR_OBJS,;t t
 s,@WANT_IRS_THREADSPW_OBJS@,$WANT_IRS_THREADSPW_OBJS,;t t
 s,@WANT_IRS_THREADS_OBJS@,$WANT_IRS_THREADS_OBJS,;t t
+s,@USE_IFNAMELINKID@,$USE_IFNAMELINKID,;t t
 s,@ISC_THREAD_DIR@,$ISC_THREAD_DIR,;t t
 s,@DAEMON_OBJS@,$DAEMON_OBJS,;t t
 s,@NEED_DAEMON@,$NEED_DAEMON,;t t
diff --git a/lib/bind/configure.in b/lib/bind/configure.in
index d3287337..7c1e4768 100644
--- a/lib/bind/configure.in
+++ b/lib/bind/configure.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-AC_REVISION($Revision: 1.83.2.7 $)
+AC_REVISION($Revision: 1.83.2.8 $)
 
 AC_INIT(resolv/herror.c)
 AC_PREREQ(2.13)
@@ -526,6 +526,11 @@ AC_SUBST(WANT_IRS_THREADSGR_OBJS)
 AC_SUBST(WANT_IRS_THREADSPW_OBJS)
 AC_SUBST(WANT_IRS_THREADS_OBJS)
 
+AC_CHECK_FUNC(if_nametoindex,
+	[USE_IFNAMELINKID="#define USE_IFNAMELINKID 1"],
+	[USE_IFNAMELINKID="#undef USE_IFNAMELINKID"])
+AC_SUBST(USE_IFNAMELINKID)
+
 ISC_THREAD_DIR=$thread_dir
 AC_SUBST(ISC_THREAD_DIR)
 
diff --git a/lib/bind/irs/getaddrinfo.c b/lib/bind/irs/getaddrinfo.c
index 31a45367..291fba16 100644
--- a/lib/bind/irs/getaddrinfo.c
+++ b/lib/bind/irs/getaddrinfo.c
@@ -1100,6 +1100,7 @@ ip6_str2scopeid(char *scope, struct sockaddr_in6 *sin6,
 		 */
 		scopeid = if_nametoindex(scope);
 		if (scopeid == 0)
+			goto trynumeric;
 		*scopeidp = scopeid;
 		return (1);
 	}
diff --git a/lib/bind/nameser/ns_print.c b/lib/bind/nameser/ns_print.c
index 965139e5..2af84b8d 100644
--- a/lib/bind/nameser/ns_print.c
+++ b/lib/bind/nameser/ns_print.c
@@ -16,7 +16,7 @@
  */
 
 #ifndef lint
-static const char rcsid[] = "$Id: ns_print.c,v 1.3.2.5 2004/03/17 01:15:49 marka Exp $";
+static const char rcsid[] = "$Id: ns_print.c,v 1.3.2.6 2004/07/28 20:06:58 marka Exp $";
 #endif
 
 /* Import. */
@@ -145,8 +145,6 @@ ns_sprintrrf(const u_char *msg, size_t msglen,
 	addlen(x, &buf, &buflen);
 	len = SPRINTF((tmp, " %s %s", p_class(class), p_type(type)));
 	T(addstr(tmp, len, &buf, &buflen));
-	if (rdlen == 0U)
-		return (buf - obuf);
 	T(spaced = addtab(x + len, 16, spaced, &buf, &buflen));
 
 	/*
@@ -707,7 +705,8 @@ ns_sprintrrf(const u_char *msg, size_t msglen,
 	int n, m;
 	char *p;
 
-	len = SPRINTF((tmp, "\\# %u (\t; %s", edata - rdata, comment));
+	len = SPRINTF((tmp, "\\# %u%s\t; %s", edata - rdata,
+		       rdlen != 0 ? " (" : "", comment));
 	T(addstr(tmp, len, &buf, &buflen));
 	while (rdata < edata) {
 		p = tmp;
diff --git a/lib/bind/port/aix32/include/sys/cdefs.h b/lib/bind/port/aix32/include/sys/cdefs.h
index 0c7c9906..be524ed4 100644
--- a/lib/bind/port/aix32/include/sys/cdefs.h
+++ b/lib/bind/port/aix32/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/04/11 01:30:12 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:33 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/aix4/include/sys/cdefs.h b/lib/bind/port/aix4/include/sys/cdefs.h
index 61fe4dcd..87d79ac2 100644
--- a/lib/bind/port/aix4/include/sys/cdefs.h
+++ b/lib/bind/port/aix4/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/10 04:23:15 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:33 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -130,7 +130,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/aux3/include/sys/cdefs.h b/lib/bind/port/aux3/include/sys/cdefs.h
index 965883ce..7c9d2412 100644
--- a/lib/bind/port/aux3/include/sys/cdefs.h
+++ b/lib/bind/port/aux3/include/sys/cdefs.h
@@ -114,7 +114,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/cygwin/include/sys/cdefs.h b/lib/bind/port/cygwin/include/sys/cdefs.h
index 158639b0..a3040e7e 100644
--- a/lib/bind/port/cygwin/include/sys/cdefs.h
+++ b/lib/bind/port/cygwin/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1.242.1 2004/03/09 09:17:42 marka Exp $
+ *	$Id: cdefs.h,v 1.1.242.2 2004/07/19 05:54:34 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/hpux/include/sys/cdefs.h b/lib/bind/port/hpux/include/sys/cdefs.h
index aca6f0a2..f6630047 100644
--- a/lib/bind/port/hpux/include/sys/cdefs.h
+++ b/lib/bind/port/hpux/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/04/09 09:17:16 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:34 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/hpux10/include/sys/cdefs.h b/lib/bind/port/hpux10/include/sys/cdefs.h
index 868f9bfa..e5903da4 100644
--- a/lib/bind/port/hpux10/include/sys/cdefs.h
+++ b/lib/bind/port/hpux10/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/17 06:25:49 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:36 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/hpux9/include/sys/cdefs.h b/lib/bind/port/hpux9/include/sys/cdefs.h
index d298c13c..e5903da4 100644
--- a/lib/bind/port/hpux9/include/sys/cdefs.h
+++ b/lib/bind/port/hpux9/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/17 06:25:50 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:36 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/irix/include/sys/cdefs.h b/lib/bind/port/irix/include/sys/cdefs.h
index d298c13c..e5903da4 100644
--- a/lib/bind/port/irix/include/sys/cdefs.h
+++ b/lib/bind/port/irix/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/17 06:25:50 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:36 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/lynxos/include/sys/cdefs.h b/lib/bind/port/lynxos/include/sys/cdefs.h
index 213e34e1..d9512b15 100644
--- a/lib/bind/port/lynxos/include/sys/cdefs.h
+++ b/lib/bind/port/lynxos/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/17 06:25:51 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:37 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -129,7 +129,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/mpe/include/sys/cdefs.h b/lib/bind/port/mpe/include/sys/cdefs.h
index 5c626438..e81cd654 100644
--- a/lib/bind/port/mpe/include/sys/cdefs.h
+++ b/lib/bind/port/mpe/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/17 06:25:51 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:37 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/next/include/sys/cdefs.h b/lib/bind/port/next/include/sys/cdefs.h
index 8f5d38ef..69a57639 100644
--- a/lib/bind/port/next/include/sys/cdefs.h
+++ b/lib/bind/port/next/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/17 06:25:55 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:38 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/qnx/include/sys/cdefs.h b/lib/bind/port/qnx/include/sys/cdefs.h
index f814b0c0..2b3f9ec5 100644
--- a/lib/bind/port/qnx/include/sys/cdefs.h
+++ b/lib/bind/port/qnx/include/sys/cdefs.h
@@ -108,8 +108,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || \
-	(__GNUC__ == 2 && __GNUC_MINOR__ < 5)
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/sco42/include/sys/cdefs.h b/lib/bind/port/sco42/include/sys/cdefs.h
index 274057c6..69a57639 100644
--- a/lib/bind/port/sco42/include/sys/cdefs.h
+++ b/lib/bind/port/sco42/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/17 06:25:57 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:38 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/solaris/include/sys/cdefs.h b/lib/bind/port/solaris/include/sys/cdefs.h
index 66950406..24b1e24f 100644
--- a/lib/bind/port/solaris/include/sys/cdefs.h
+++ b/lib/bind/port/solaris/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/04/02 06:29:20 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:39 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/sunos/include/sys/cdefs.h b/lib/bind/port/sunos/include/sys/cdefs.h
index ce95a0e0..24b1e24f 100644
--- a/lib/bind/port/sunos/include/sys/cdefs.h
+++ b/lib/bind/port/sunos/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/17 06:25:58 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:39 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/unixware20/include/sys/cdefs.h b/lib/bind/port/unixware20/include/sys/cdefs.h
index 8b662a1c..f865564c 100644
--- a/lib/bind/port/unixware20/include/sys/cdefs.h
+++ b/lib/bind/port/unixware20/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/17 06:26:00 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:40 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port/unixware212/include/sys/cdefs.h b/lib/bind/port/unixware212/include/sys/cdefs.h
index fa97a4f2..f865564c 100644
--- a/lib/bind/port/unixware212/include/sys/cdefs.h
+++ b/lib/bind/port/unixware212/include/sys/cdefs.h
@@ -55,7 +55,7 @@
 
 /*
  *	@(#)cdefs.h	8.1 (Berkeley) 6/2/93
- *	$Id: cdefs.h,v 1.1 2001/05/17 06:26:01 marka Exp $
+ *	$Id: cdefs.h,v 1.1.2.1 2004/07/19 05:54:40 marka Exp $
  */
 
 #ifndef	_CDEFS_H_
@@ -127,7 +127,7 @@
  * these work for GNU C++ (modulo a slight glitch in the C++ grammar
  * in the distribution version of 2.5.5).
  */
-#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
+#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5)
 #define	__attribute__(x)	/* delete __attribute__ if non-gcc or gcc1 */
 #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
 #define	__dead		__volatile
diff --git a/lib/bind/port_after.h.in b/lib/bind/port_after.h.in
index 9095982e..6d5f4dca 100644
--- a/lib/bind/port_after.h.in
+++ b/lib/bind/port_after.h.in
@@ -26,6 +26,7 @@
 @USE_SYSERROR_LIST@
 @INNETGR_ARGS@
 @SETNETGRENT_ARGS@
+@USE_IFNAMELINKID@
 
 /* XXX sunos and cygwin needs O_NDELAY */
 #define PORT_NONBLOCK O_NONBLOCK
diff --git a/lib/bind/resolv/res_debug.c b/lib/bind/resolv/res_debug.c
index c7b61775..956e2c5c 100644
--- a/lib/bind/resolv/res_debug.c
+++ b/lib/bind/resolv/res_debug.c
@@ -95,7 +95,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static const char sccsid[] = "@(#)res_debug.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: res_debug.c,v 1.3.2.9 2004/04/13 06:57:23 marka Exp $";
+static const char rcsid[] = "$Id: res_debug.c,v 1.3.2.10 2004/07/28 20:06:58 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include "port_before.h"
@@ -549,7 +549,7 @@ p_type(int type) {
 	result = sym_ntos(__p_type_syms, type, &success);
 	if (success)
 		return (result);
-	if (type < 0 || type > 0xfff)
+	if (type < 0 || type > 0xffff)
 		return ("BADTYPE");
 	sprintf(typebuf, "TYPE%d", type);
 	return (typebuf);
@@ -585,7 +585,7 @@ p_class(int class) {
 	result = sym_ntos(__p_class_syms, class, &success);
 	if (success)
 		return (result);
-	if (class < 0 || class > 0xfff)
+	if (class < 0 || class > 0xffff)
 		return ("BADCLASS");
 	sprintf(classbuf, "CLASS%d", class);
 	return (classbuf);
diff --git a/lib/bind/resolv/res_send.c b/lib/bind/resolv/res_send.c
index 6931189a..03869d64 100644
--- a/lib/bind/resolv/res_send.c
+++ b/lib/bind/resolv/res_send.c
@@ -70,7 +70,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static const char sccsid[] = "@(#)res_send.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: res_send.c,v 1.5.2.6 2004/06/03 04:38:11 marka Exp $";
+static const char rcsid[] = "$Id: res_send.c,v 1.5.2.7 2004/08/10 02:27:36 marka Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 /*
@@ -172,7 +172,8 @@ res_ourserver_p(const res_state statp, const struct sockaddr *sa) {
 			if (srv6->sin6_family == in6p->sin6_family &&
 			    srv6->sin6_port == in6p->sin6_port &&
 #ifdef HAVE_SIN6_SCOPE_ID
-			    srv6->sin6_scope_id == in6p->sin6_scope_id &&
+			    (srv6->sin6_scope_id == 0 ||
+			     srv6->sin6_scope_id == in6p->sin6_scope_id) &&
 #endif
 			    (IN6_IS_ADDR_UNSPECIFIED(&srv6->sin6_addr) ||
 			     IN6_ARE_ADDR_EQUAL(&srv6->sin6_addr, &in6p->sin6_addr)))
diff --git a/lib/dns/Makefile.in b/lib/dns/Makefile.in
index a8bc346f..6973c20b 100644
--- a/lib/dns/Makefile.in
+++ b/lib/dns/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.126.2.9 2004/04/15 00:35:27 marka Exp $
+# $Id: Makefile.in,v 1.126.2.10 2004/07/20 07:00:19 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -105,7 +105,7 @@ libdns.@SA@: ${OBJS}
 
 libdns.la: ${OBJS}
 	${LIBTOOL_MODE_LINK} \
-		${CC} ${ALL_CFLAGS} -o libdns.la -rpath ${libdir} \
+		${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libdns.la -rpath ${libdir} \
 		-version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \
 		${OBJS} ${ISCLIBS} @DNS_OPENSSL_LIBS@ ${LIBS}
 
@@ -115,7 +115,7 @@ libdstcypto.@SA@: ${OPENSSLOBJS}
 
 libdstcypto.la: ${OPENSSLOBJS}
 	${LIBTOOL_MODE_LINK} \
-		${CC} ${ALL_CFLAGS} -o $@ -rpath ${libdir} \
+		${CC} ${ALL_CFLAGS} ${LDFLAGS} -o $@ -rpath ${libdir} \
 		-version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \
 		${OPENSSLOBJS} ${LIBS}
 
@@ -125,7 +125,7 @@ libdstgssapi.@SA@: ${GSSAPIOBJS}
 
 libdstgssapi.la: ${GSSAPIOBJS}
 	${LIBTOOL_MODE_LINK} \
-		${CC} ${ALL_CFLAGS} -o $@ -rpath ${libdir} \
+		${CC} ${ALL_CFLAGS} ${LDFLAGS} -o $@ -rpath ${libdir} \
 		-version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \
 		${GSSAPIOBJS} ${LIBS}
 
@@ -169,7 +169,7 @@ code.h:	gen
 	./gen -s ${srcdir} > code.h
 
 gen: gen.c
-	${CC} ${ALL_CFLAGS} -o $@ ${srcdir}/gen.c ${LIBS}
+	${CC} ${ALL_CFLAGS} ${LDFLAGS} -o $@ ${srcdir}/gen.c ${LIBS}
 
 rbtdb64.@O@: rbtdb.c
 
diff --git a/lib/dns/api b/lib/dns/api
index c88c1d07..04d16633 100644
--- a/lib/dns/api
+++ b/lib/dns/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 12
-LIBREVISION = 4
+LIBREVISION = 5
 LIBAGE = 1
diff --git a/lib/dns/dispatch.c b/lib/dns/dispatch.c
index ad4f30c3..a999032e 100644
--- a/lib/dns/dispatch.c
+++ b/lib/dns/dispatch.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dispatch.c,v 1.101.2.10 2004/04/15 02:16:26 marka Exp $ */
+/* $Id: dispatch.c,v 1.101.2.11 2004/07/21 00:49:02 marka Exp $ */
 
 #include <config.h>
 
@@ -160,7 +160,7 @@ static void free_buffer(dns_dispatch_t *disp, void *buf, unsigned int len);
 static void *allocate_udp_buffer(dns_dispatch_t *disp);
 static inline void free_event(dns_dispatch_t *disp, dns_dispatchevent_t *ev);
 static inline dns_dispatchevent_t *allocate_event(dns_dispatch_t *disp);
-static void do_cancel(dns_dispatch_t *disp, dns_dispentry_t *resp);
+static void do_cancel(dns_dispatch_t *disp);
 static dns_dispentry_t *linear_first(dns_qid_t *disp);
 static dns_dispentry_t *linear_next(dns_qid_t *disp,
 				    dns_dispentry_t *resp);
@@ -625,26 +625,25 @@ udp_recv(isc_task_t *task, isc_event_t *ev_in) {
 		/* query */
 		free_buffer(disp, ev->region.base, ev->region.length);
 		goto restart;
-	} else {
- 		/* response */
-		bucket = dns_hash(qid, &ev->address, id);
-		LOCK(&qid->lock);
-		resp = bucket_search(qid, &ev->address, id, bucket);
-		UNLOCK(&qid->lock);
-		dispatch_log(disp, LVL(90),
-			     "search for response in bucket %d: %s",
-			     bucket, (resp == NULL ? "not found" : "found"));
-
-		if (resp == NULL) {
-			free_buffer(disp, ev->region.base, ev->region.length);
-			goto restart;
-		} 
-		queue_response = resp->item_out;
-		rev = allocate_event(resp->disp);
-		if (rev == NULL) {
-			free_buffer(disp, ev->region.base, ev->region.length);
-			goto restart;
-		}
+	}
+
+	/* response */
+	bucket = dns_hash(qid, &ev->address, id);
+	LOCK(&qid->lock);
+	resp = bucket_search(qid, &ev->address, id, bucket);
+	dispatch_log(disp, LVL(90),
+		     "search for response in bucket %d: %s",
+		     bucket, (resp == NULL ? "not found" : "found"));
+
+	if (resp == NULL) {
+		free_buffer(disp, ev->region.base, ev->region.length);
+		goto unlock;
+	} 
+	queue_response = resp->item_out;
+	rev = allocate_event(resp->disp);
+	if (rev == NULL) {
+		free_buffer(disp, ev->region.base, ev->region.length);
+		goto unlock;
 	}
 
 	/*
@@ -672,6 +671,8 @@ udp_recv(isc_task_t *task, isc_event_t *ev_in) {
 		resp->item_out = ISC_TRUE;
 		isc_task_send(resp->task, ISC_EVENT_PTR(&rev));
 	}
+ unlock:
+	UNLOCK(&qid->lock);
 
 	/*
 	 * Restart recv() to get the next packet.
@@ -742,7 +743,7 @@ tcp_recv(isc_task_t *task, isc_event_t *ev_in) {
 			
 		case ISC_R_EOF:
 			dispatch_log(disp, LVL(90), "shutting down on EOF");
-			do_cancel(disp, NULL);
+			do_cancel(disp);
 			break;
 
 		default:
@@ -750,7 +751,7 @@ tcp_recv(isc_task_t *task, isc_event_t *ev_in) {
 				     "shutting down due to TCP "
 				     "receive error: %s",
 				     isc_result_totext(tcpmsg->result));
-			do_cancel(disp, NULL);
+			do_cancel(disp);
 			break;
 		}
 
@@ -806,27 +807,26 @@ tcp_recv(isc_task_t *task, isc_event_t *ev_in) {
 		 * Query.
 		 */
 		goto restart;
-	} else {
- 		/*
-		 * Response.
-		 */
-		bucket = dns_hash(qid, &tcpmsg->address, id);
-		LOCK(&qid->lock);
-		resp = bucket_search(qid, &tcpmsg->address, id, bucket);
-		UNLOCK(&qid->lock);
-		dispatch_log(disp, LVL(90),
-			     "search for response in bucket %d: %s",
-			     bucket, (resp == NULL ? "not found" : "found"));
-
-		if (resp == NULL)
-			goto restart;
-		queue_response = resp->item_out;
-		rev = allocate_event(disp);
-		if (rev == NULL)
-			goto restart;
 	}
 
 	/*
+	 * Response.
+	 */
+	bucket = dns_hash(qid, &tcpmsg->address, id);
+	LOCK(&qid->lock);
+	resp = bucket_search(qid, &tcpmsg->address, id, bucket);
+	dispatch_log(disp, LVL(90),
+		     "search for response in bucket %d: %s",
+		     bucket, (resp == NULL ? "not found" : "found"));
+
+	if (resp == NULL)
+		goto unlock;
+	queue_response = resp->item_out;
+	rev = allocate_event(disp);
+	if (rev == NULL)
+		goto unlock;
+
+	/*
 	 * At this point, rev contains the event we want to fill in, and
 	 * resp contains the information on the place to send it to.
 	 * Send the event off.
@@ -848,6 +848,8 @@ tcp_recv(isc_task_t *task, isc_event_t *ev_in) {
 		resp->item_out = ISC_TRUE;
 		isc_task_send(resp->task, ISC_EVENT_PTR(&rev));
 	}
+ unlock:
+	UNLOCK(&qid->lock);
 
 	/*
 	 * Restart recv() to get the next packet.
@@ -895,7 +897,7 @@ startrecv(dns_dispatch_t *disp) {
 			free_buffer(disp, region.base, region.length);
 			disp->shutdown_why = res;
 			disp->shutting_down = 1;
-			do_cancel(disp, NULL);
+			do_cancel(disp);
 			return;
 		}
 		disp->recv_pending = 1;
@@ -907,7 +909,7 @@ startrecv(dns_dispatch_t *disp) {
 		if (res != ISC_R_SUCCESS) {
 			disp->shutdown_why = res;
 			disp->shutting_down = 1;
-			do_cancel(disp, NULL);
+			do_cancel(disp);
 			return;
 		}
 		disp->recv_pending = 1;
@@ -1924,7 +1926,7 @@ dns_dispatch_removeresponse(dns_dispentry_t **resp,
 	res->magic = 0;
 	isc_mempool_put(disp->mgr->rpool, res);
 	if (disp->shutting_down == 1)
-		do_cancel(disp, NULL);
+		do_cancel(disp);
 	else
 		startrecv(disp);
 
@@ -1935,8 +1937,9 @@ dns_dispatch_removeresponse(dns_dispentry_t **resp,
 }
 
 static void
-do_cancel(dns_dispatch_t *disp, dns_dispentry_t *resp) {
+do_cancel(dns_dispatch_t *disp) {
 	dns_dispatchevent_t *ev;
+	dns_dispentry_t *resp;
 	dns_qid_t *qid;
 
 	if (disp->shutdown_out == 1)
@@ -1947,28 +1950,16 @@ do_cancel(dns_dispatch_t *disp, dns_dispentry_t *resp) {
 	/*
 	 * Search for the first response handler without packets outstanding.
 	 */
-	if (resp == NULL) {
-		LOCK(&qid->lock);
-		resp = linear_first(qid);
-		if (resp == NULL) {
-			/* no first item? */
-			UNLOCK(&qid->lock);
-			return;
-		}
-		do {
-			if (resp->item_out == ISC_FALSE)
-				break;
-
-			resp = linear_next(qid, resp);
-		} while (resp != NULL);
-		UNLOCK(&qid->lock);
-	}
-
+	LOCK(&qid->lock);
+	for (resp = linear_first(qid);
+	     resp != NULL && resp->item_out != ISC_FALSE;
+	     /* Empty. */)
+		resp = linear_next(qid, resp);
 	/*
 	 * No one to send the cancel event to, so nothing to do.
 	 */
 	if (resp == NULL)
-		return;
+		goto unlock;
 
 	/*
 	 * Send the shutdown failsafe event to this resp.
@@ -1985,6 +1976,8 @@ do_cancel(dns_dispatch_t *disp, dns_dispentry_t *resp) {
 		    ev, resp->task);
 	resp->item_out = ISC_TRUE;
 	isc_task_send(resp->task, ISC_EVENT_PTR(&ev));
+ unlock:
+	UNLOCK(&qid->lock);
 }
 
 isc_socket_t *
@@ -2020,7 +2013,7 @@ dns_dispatch_cancel(dns_dispatch_t *disp) {
 
 	disp->shutdown_why = ISC_R_CANCELED;
 	disp->shutting_down = 1;
-	do_cancel(disp, NULL);
+	do_cancel(disp);
 
 	UNLOCK(&disp->lock);
 
diff --git a/lib/dns/include/dns/name.h b/lib/dns/include/dns/name.h
index e7e34e10..41cc5995 100644
--- a/lib/dns/include/dns/name.h
+++ b/lib/dns/include/dns/name.h
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: name.h,v 1.95.2.5 2004/03/09 06:11:19 marka Exp $ */
+/* $Id: name.h,v 1.95.2.7 2004/08/10 00:41:49 marka Exp $ */
 
 #ifndef DNS_NAME_H
 #define DNS_NAME_H 1
@@ -663,6 +663,9 @@ dns_name_getlabelsequence(const dns_name_t *source, unsigned int first,
  * Notes:
  *	Numbering starts at 0.
  *
+ *	Given "rc.vix.com.", the label 0 is "rc", and label 3 is the
+ *	root label.
+ *
  *	'target' refers to the same memory as 'source', so 'source'
  *	must not be changed while 'target' is still in use.
  *
@@ -1341,7 +1344,7 @@ do { \
 do { \
 	(r)->base = (n)->ndata; \
 	(r)->length = (n)->length; \
-} while (0);
+} while (0)
 
 
 #ifdef DNS_NAME_USEINLINE
diff --git a/lib/dns/sdb.c b/lib/dns/sdb.c
index eb6d38aa..c810cd42 100644
--- a/lib/dns/sdb.c
+++ b/lib/dns/sdb.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdb.c,v 1.35.2.5 2004/04/15 01:38:08 marka Exp $ */
+/* $Id: sdb.c,v 1.35.2.6 2004/07/22 04:04:41 marka Exp $ */
 
 #include <config.h>
 
@@ -577,10 +577,10 @@ attachversion(dns_db_t *db, dns_dbversion_t *source,
 	      dns_dbversion_t **targetp)
 {
 	REQUIRE(source != NULL && source == (void *) &dummy);
+	REQUIRE(targetp != NULL && *targetp == NULL);
 
 	UNUSED(db);
-	UNUSED(source);
-	UNUSED(targetp);
+	*targetp = source;
 	return;
 }
 
diff --git a/lib/isc/Makefile.in b/lib/isc/Makefile.in
index cb2a84a0..158ca13a 100644
--- a/lib/isc/Makefile.in
+++ b/lib/isc/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.71.2.5 2004/03/09 06:11:44 marka Exp $
+# $Id: Makefile.in,v 1.71.2.6 2004/07/20 07:00:19 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -94,7 +94,7 @@ libisc.@SA@: ${OBJS}
 
 libisc.la: ${OBJS}
 	${LIBTOOL_MODE_LINK} \
-		${CC} ${ALL_CFLAGS} -o libisc.la -rpath ${libdir} \
+		${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libisc.la -rpath ${libdir} \
 		-version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \
 		${OBJS} ${LIBS}
 
diff --git a/lib/isccc/Makefile.in b/lib/isccc/Makefile.in
index dd98bafe..83a80705 100644
--- a/lib/isccc/Makefile.in
+++ b/lib/isccc/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.4 2004/03/09 06:12:25 marka Exp $
+# $Id: Makefile.in,v 1.2.2.5 2004/07/20 07:00:20 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -69,7 +69,7 @@ libisccc.@SA@: ${OBJS}
 
 libisccc.la: ${OBJS}
 	${LIBTOOL_MODE_LINK} \
-		${CC} ${ALL_CFLAGS} -o libisccc.la -rpath ${libdir} \
+		${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libisccc.la -rpath ${libdir} \
 		-version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \
 		${OBJS} ${LIBS} ${ISCLIBS}
 
diff --git a/lib/isccfg/Makefile.in b/lib/isccfg/Makefile.in
index d248e7b0..66e2d807 100644
--- a/lib/isccfg/Makefile.in
+++ b/lib/isccfg/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.6.2.4 2004/03/09 06:12:30 marka Exp $
+# $Id: Makefile.in,v 1.6.2.5 2004/07/20 07:00:20 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -66,7 +66,7 @@ libisccfg.@SA@: ${OBJS}
 
 libisccfg.la: ${OBJS}
 	 ${LIBTOOL_MODE_LINK} \
-		${CC} ${ALL_CFLAGS} -o libisccfg.la -rpath ${libdir} \
+		${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libisccfg.la -rpath ${libdir} \
 		-version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \
 		${OBJS} ${LIBS} ${DNSLIBS} ${ISCCCLIBS} ${ISCLIBS}
 
diff --git a/lib/isccfg/api b/lib/isccfg/api
index cff58c8e..1bdcb768 100644
--- a/lib/isccfg/api
+++ b/lib/isccfg/api
@@ -1,3 +1,3 @@
 LIBINTERFACE = 0
-LIBREVISION = 10
+LIBREVISION = 11
 LIBAGE = 0
diff --git a/lib/isccfg/check.c b/lib/isccfg/check.c
index 3e4a40b5..41569102 100644
--- a/lib/isccfg/check.c
+++ b/lib/isccfg/check.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: check.c,v 1.14.2.24 2004/05/17 06:18:40 marka Exp $ */
+/* $Id: check.c,v 1.14.2.25 2004/07/29 00:08:17 marka Exp $ */
 
 #include <config.h>
 
@@ -660,8 +660,17 @@ cfg_check_namedconf(cfg_obj_t *config, isc_log_t *logctx, isc_mem_t *mctx) {
 				cfg_obj_log(view, logctx, ISC_LOG_ERROR,
 					    "view '%s': already exists", key);
 				result = tresult;
-			} else if (result != ISC_R_SUCCESS)
+			} else if (result != ISC_R_SUCCESS) {
 				result = tresult;
+			} else if ((strcasecmp(key, "_bind") == 0 &&
+				    vclass == dns_rdataclass_ch) ||
+				   (strcasecmp(key, "_default") == 0 &&
+				    vclass == dns_rdataclass_in)) {
+				cfg_obj_log(view, logctx, ISC_LOG_ERROR,
+					    "attempt to redefine builtin view "
+					    "'%s'", key);
+				result = ISC_R_EXISTS;
+			}
 		}
 		if (check_viewconf(config, voptions, logctx, mctx)
 		    != ISC_R_SUCCESS)
diff --git a/lib/lwres/Makefile.in b/lib/lwres/Makefile.in
index e41ddb45..a5342482 100644
--- a/lib/lwres/Makefile.in
+++ b/lib/lwres/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.25.2.2 2004/03/09 06:12:32 marka Exp $
+# $Id: Makefile.in,v 1.25.2.3 2004/07/20 07:00:20 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -65,7 +65,7 @@ liblwres.@SA@: ${OBJS} version.@O@
 
 liblwres.la: ${OBJS} version.@O@
 	${LIBTOOL_MODE_LINK} \
-		${CC} ${ALL_CFLAGS} -o liblwres.la -rpath ${libdir} \
+		${CC} ${ALL_CFLAGS} ${LDFLAGS} -o liblwres.la -rpath ${libdir} \
 		-version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \
 		${OBJS} version.@O@ ${LIBS}
 
diff --git a/lib/tests/Makefile.in b/lib/tests/Makefile.in
index 131c64ec..072c0022 100644
--- a/lib/tests/Makefile.in
+++ b/lib/tests/Makefile.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.14.2.4 2004/03/09 06:12:44 marka Exp $
+# $Id: Makefile.in,v 1.14.2.5 2004/07/20 07:00:21 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -46,7 +46,7 @@ libt_api.@SA@: ${OBJS}
 
 libt_api.la: ${OBJS}
 	${LIBTOOL_MODE_LINK} \
-		${CC} ${ALL_CFLAGS} -o libt_api.la -rpath ${libdir} \
+		${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libt_api.la -rpath ${libdir} \
 		${OBJS} ${ISCLIBS} ${LIBS} -allow-undefined
 
 timestamp: libt_api.@A@
diff --git a/make/rules.in b/make/rules.in
index 19e6d356..f4e880f7 100644
--- a/make/rules.in
+++ b/make/rules.in
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: rules.in,v 1.40.2.8 2004/03/09 06:12:46 marka Exp $
+# $Id: rules.in,v 1.40.2.9 2004/07/20 07:00:21 marka Exp $
 
 ###
 ### Common Makefile rules for BIND 9.
@@ -87,6 +87,7 @@ install clean distclean maintainer-clean doc docclean man manclean::
 ###	CC
 ### Makefile may define
 ###	CFLAGS
+###	LDFLAGS
 ###	CINCLUDES
 ###	CDEFINES
 ###	CWARNINGS
@@ -95,6 +96,7 @@ install clean distclean maintainer-clean doc docclean man manclean::
 
 CC = 		@CC@
 CFLAGS =	@CFLAGS@
+LDFLAGS =	@LDFLAGS@
 STD_CINCLUDES =	@STD_CINCLUDES@
 STD_CDEFINES =	@STD_CDEFINES@
 STD_CWARNINGS =	@STD_CWARNINGS@
diff --git a/version b/version
index 5d2b8c38..fa4b278c 100644
--- a/version
+++ b/version
@@ -1,4 +1,4 @@
-# $Id: version,v 1.26.2.28 2004/07/01 02:10:19 marka Exp $
+# $Id: version,v 1.26.2.29 2004/08/11 05:30:43 marka Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
@@ -7,4 +7,4 @@ MAJORVER=9
 MINORVER=2
 PATCHVER=4
 RELEASETYPE=rc
-RELEASEVER=6
+RELEASEVER=7