31 files changed, 0 insertions, 23572 deletions

diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.8 b/contrib/bind9/bin/dnssec/dnssec-makekeyset.8
deleted file mode 100644
index 0189b31e62e5..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-makekeyset.8
+++ /dev/null
@@ -1,113 +0,0 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
-.\"
-.\" Permission to use, copy, modify, and distribute this software for any
-.\" purpose with or without fee is hereby granted, provided that the above
-.\" copyright notice and this permission notice appear in all copies.
-.\"
-.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-.\" PERFORMANCE OF THIS SOFTWARE.
-.\"
-.\" $Id: dnssec-makekeyset.8,v 1.16.2.2.4.1 2004/03/06 07:41:39 marka Exp $
-.\"
-.TH "DNSSEC-MAKEKEYSET" "8" "June 30, 2000" "BIND9" ""
-.SH NAME
-dnssec-makekeyset \- DNSSEC zone signing tool
-.SH SYNOPSIS
-.sp
-\fBdnssec-makekeyset\fR [ \fB-a\fR ]  [ \fB-s \fIstart-time\fB\fR ]  [ \fB-e \fIend-time\fB\fR ]  [ \fB-h\fR ]  [ \fB-p\fR ]  [ \fB-r \fIrandomdev\fB\fR ]  [ \fB-t\fIttl\fB\fR ]  [ \fB-v \fIlevel\fB\fR ]  \fBkey\fR\fI...\fR
-.SH "DESCRIPTION"
-.PP
-\fBdnssec-makekeyset\fR generates a key set from one
-or more keys created by \fBdnssec-keygen\fR. It creates
-a file containing a KEY record for each key, and self-signs the key
-set with each zone key. The output file is of the form
-\fIkeyset-nnnn.\fR, where \fInnnn\fR
-is the zone name.
-.SH "OPTIONS"
-.TP
-\fB-a\fR
-Verify all generated signatures.
-.TP
-\fB-s \fIstart-time\fB\fR
-Specify the date and time when the generated SIG records
-become valid. This can be either an absolute or relative
-time. An absolute start time is indicated by a number
-in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-14:45:00 UTC on May 30th, 2000. A relative start time is
-indicated by +N, which is N seconds from the current time.
-If no \fBstart-time\fR is specified, the current
-time is used.
-.TP
-\fB-e \fIend-time\fB\fR
-Specify the date and time when the generated SIG records
-expire. As with \fBstart-time\fR, an absolute
-time is indicated in YYYYMMDDHHMMSS notation. A time relative
-to the start time is indicated with +N, which is N seconds from
-the start time. A time relative to the current time is
-indicated with now+N. If no \fBend-time\fR is
-specified, 30 days from the start time is used as a default.
-.TP
-\fB-h\fR
-Prints a short summary of the options and arguments to
-\fBdnssec-makekeyset\fR.
-.TP
-\fB-p\fR
-Use pseudo-random data when signing the zone. This is faster,
-but less secure, than using real random data. This option
-may be useful when signing large zones or when the entropy
-source is limited.
-.TP
-\fB-r \fIrandomdev\fB\fR
-Specifies the source of randomness. If the operating
-system does not provide a \fI/dev/random\fR
-or equivalent device, the default source of randomness
-is keyboard input. \fIrandomdev\fR specifies
-the name of a character device or file containing random
-data to be used instead of the default. The special value
-\fIkeyboard\fR indicates that keyboard
-input should be used.
-.TP
-\fB-t \fIttl\fB\fR
-Specify the TTL (time to live) of the KEY and SIG records.
-The default is 3600 seconds.
-.TP
-\fB-v \fIlevel\fB\fR
-Sets the debugging level.
-.TP
-\fBkey\fR
-The list of keys to be included in the keyset file. These keys
-are expressed in the form \fIKnnnn.+aaa+iiiii\fR
-as generated by \fBdnssec-keygen\fR.
-.SH "EXAMPLE"
-.PP
-The following command generates a keyset containing the DSA key for
-\fBexample.com\fR generated in the
-\fBdnssec-keygen\fR man page.
-.PP
-\fBdnssec-makekeyset -t 86400 -s 20000701120000 -e +2592000 Kexample.com.+003+26160\fR
-.PP
-In this example, \fBdnssec-makekeyset\fR creates
-the file \fIkeyset-example.com.\fR. This file
-contains the specified key and a self-generated signature.
-.PP
-The DNS administrator for \fBexample.com\fR could
-send \fIkeyset-example.com.\fR to the DNS
-administrator for \fB.com\fR for signing, if the
-\&.com zone is DNSSEC-aware and the administrators of the two zones
-have some mechanism for authenticating each other and exchanging
-the keys and signatures securely.
-.SH "SEE ALSO"
-.PP
-\fBdnssec-keygen\fR(8),
-\fBdnssec-signkey\fR(8),
-\fIBIND 9 Administrator Reference Manual\fR,
-\fIRFC 2535\fR.
-.SH "AUTHOR"
-.PP
-Internet Software Consortium
diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.c b/contrib/bind9/bin/dnssec/dnssec-makekeyset.c
deleted file mode 100644
index c8224ed3888f..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-makekeyset.c
+++ /dev/null
@@ -1,401 +0,0 @@
-/*
- * Portions Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright (C) 2000-2003  Internet Software Consortium.
- * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
- *
- * Permission to use, copy, modify, and distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND ISC AND NETWORK ASSOCIATES DISCLAIMS
- * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE
- * FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR
- * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-/* $Id: dnssec-makekeyset.c,v 1.52.2.1.10.7 2004/08/28 06:25:27 marka Exp $ */
-
-#include <config.h>
-
-#include <stdlib.h>
-
-#include <isc/commandline.h>
-#include <isc/entropy.h>
-#include <isc/mem.h>
-#include <isc/print.h>
-#include <isc/string.h>
-#include <isc/util.h>
-
-#include <dns/db.h>
-#include <dns/diff.h>
-#include <dns/dnssec.h>
-#include <dns/fixedname.h>
-#include <dns/log.h>
-#include <dns/rdata.h>
-#include <dns/rdataset.h>
-#include <dns/result.h>
-#include <dns/secalg.h>
-#include <dns/time.h>
-
-#include <dst/dst.h>
-
-#include "dnssectool.h"
-
-const char *program = "dnssec-makekeyset";
-int verbose;
-
-typedef struct keynode keynode_t;
-struct keynode {
-	dst_key_t *key;
-	ISC_LINK(keynode_t) link;
-};
-typedef ISC_LIST(keynode_t) keylist_t;
-
-static isc_stdtime_t starttime = 0, endtime = 0, now;
-static int ttl = -1;
-
-static isc_mem_t *mctx = NULL;
-static isc_entropy_t *ectx = NULL;
-
-static keylist_t keylist;
-
-static void
-usage(void) {
-	fprintf(stderr, "Usage:\n");
-	fprintf(stderr, "\t%s [options] keys\n", program);
-
-	fprintf(stderr, "\n");
-
-	fprintf(stderr, "Version: %s\n", VERSION);
-
-	fprintf(stderr, "Options: (default value in parenthesis) \n");
-	fprintf(stderr, "\t-a\n");
-	fprintf(stderr, "\t\tverify generated signatures\n");
-	fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n");
-	fprintf(stderr, "\t\tSIG start time - absolute|offset (now)\n");
-	fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n");
-	fprintf(stderr, "\t\tSIG end time  - "
-			     "absolute|from start|from now (now + 30 days)\n");
-	fprintf(stderr, "\t-t ttl\n");
-	fprintf(stderr, "\t-p\n");
-	fprintf(stderr, "\t\tuse pseudorandom data (faster but less secure)\n");
-	fprintf(stderr, "\t-r randomdev:\n");
-	fprintf(stderr, "\t\ta file containing random data\n");
-	fprintf(stderr, "\t-v level:\n");
-	fprintf(stderr, "\t\tverbose level (0)\n");
-
-	fprintf(stderr, "\n");
-
-	fprintf(stderr, "keys:\n");
-	fprintf(stderr, "\tkeyfile (Kname+alg+tag)\n");
-
-	fprintf(stderr, "\n");
-
-	fprintf(stderr, "Output:\n");
-	fprintf(stderr, "\tkeyset (keyset-<name>)\n");
-	exit(0);
-}
-
-static isc_boolean_t
-zonekey_on_list(dst_key_t *key) {
-	keynode_t *keynode;
-	for (keynode = ISC_LIST_HEAD(keylist);
-	     keynode != NULL;
-	     keynode = ISC_LIST_NEXT(keynode, link))
-	{
-		if (dst_key_compare(keynode->key, key))
-			return (ISC_TRUE);
-	}
-	return (ISC_FALSE);
-}
-
-int
-main(int argc, char *argv[]) {
-	int i, ch;
-	char *startstr = NULL, *endstr = NULL;
-	dns_fixedname_t fdomain;
-	dns_name_t *domain = NULL;
-	char *output = NULL;
-	char *endp;
-	unsigned char data[65536];
-	dns_db_t *db;
-	dns_dbversion_t *version;
-	dns_diff_t diff;
-	dns_difftuple_t *tuple;
-	dns_fixedname_t tname;
-	dst_key_t *key = NULL;
-	dns_rdata_t rdata = DNS_RDATA_INIT;
-	dns_rdataset_t rdataset;
-	dns_rdataclass_t rdclass;
-	isc_result_t result;
-	isc_buffer_t b;
-	isc_region_t r;
-	isc_log_t *log = NULL;
-	keynode_t *keynode;
-	unsigned int eflags;
-	isc_boolean_t pseudorandom = ISC_FALSE;
-	isc_boolean_t tryverify = ISC_FALSE;
-
-	result = isc_mem_create(0, 0, &mctx);
-	if (result != ISC_R_SUCCESS)
-		fatal("failed to create memory context: %s",
-		      isc_result_totext(result));
-
-	dns_result_register();
-
-	while ((ch = isc_commandline_parse(argc, argv, "as:e:t:r:v:ph")) != -1)
-	{
-		switch (ch) {
-		case 'a':
-			tryverify = ISC_TRUE;
-			break;
-		case 's':
-			startstr = isc_commandline_argument;
-			break;
-
-		case 'e':
-			endstr = isc_commandline_argument;
-			break;
-
-		case 't':
-			endp = NULL;
-			ttl = strtol(isc_commandline_argument, &endp, 0);
-			if (*endp != '\0')
-				fatal("TTL must be numeric");
-			break;
-
-		case 'r':
-			setup_entropy(mctx, isc_commandline_argument, &ectx);
-			break;
-
-		case 'v':
-			endp = NULL;
-			verbose = strtol(isc_commandline_argument, &endp, 0);
-			if (*endp != '\0')
-				fatal("verbose level must be numeric");
-			break;
-
-		case 'p':
-			pseudorandom = ISC_TRUE;
-			break;
-
-		case 'h':
-		default:
-			usage();
-
-		}
-	}
-
-	argc -= isc_commandline_index;
-	argv += isc_commandline_index;
-
-	if (argc < 1)
-		usage();
-
-	if (ectx == NULL)
-		setup_entropy(mctx, NULL, &ectx);
-	eflags = ISC_ENTROPY_BLOCKING;
-	if (!pseudorandom)
-		eflags |= ISC_ENTROPY_GOODONLY;
-	result = dst_lib_init(mctx, ectx, eflags);
-	if (result != ISC_R_SUCCESS)
-		fatal("could not initialize dst: %s", 
-		      isc_result_totext(result));
-
-	isc_stdtime_get(&now);
-
-	if (startstr != NULL)
-		starttime = strtotime(startstr, now, now);
-	else
-		starttime = now;
-
-	if (endstr != NULL)
-		endtime = strtotime(endstr, now, starttime);
-	else
-		endtime = starttime + (30 * 24 * 60 * 60);
-
-	if (ttl == -1) {
-		ttl = 3600;
-		fprintf(stderr, "%s: TTL not specified, assuming 3600\n",
-			program);
-	}
-
-	setup_logging(verbose, mctx, &log);
-
-	dns_diff_init(mctx, &diff);
-	rdclass = 0;
-
-	ISC_LIST_INIT(keylist);
-
-	for (i = 0; i < argc; i++) {
-		char namestr[DNS_NAME_FORMATSIZE];
-		isc_buffer_t namebuf;
-
-		key = NULL;
-		result = dst_key_fromnamedfile(argv[i], DST_TYPE_PUBLIC,
-					       mctx, &key);
-		if (result != ISC_R_SUCCESS)
-			fatal("error loading key from %s: %s", argv[i],
-			      isc_result_totext(result));
-		if (rdclass == 0)
-			rdclass = dst_key_class(key);
-
-		isc_buffer_init(&namebuf, namestr, sizeof(namestr));
-		result = dns_name_tofilenametext(dst_key_name(key),
-						 ISC_FALSE,
-						 &namebuf);
-		check_result(result, "dns_name_tofilenametext");
-		isc_buffer_putuint8(&namebuf, 0);
-
-		if (domain == NULL) {
-			dns_fixedname_init(&fdomain);
-			domain = dns_fixedname_name(&fdomain);
-			dns_name_copy(dst_key_name(key), domain, NULL);
-		} else if (!dns_name_equal(domain, dst_key_name(key))) {
-			char str[DNS_NAME_FORMATSIZE];
-			dns_name_format(domain, str, sizeof(str));
-			fatal("all keys must have the same owner - %s "
-			      "and %s do not match", str, namestr);
-		}
-
-		if (output == NULL) {
-			output = isc_mem_allocate(mctx,
-						  strlen("keyset-") +
-						  strlen(namestr) + 1);
-			if (output == NULL)
-				fatal("out of memory");
-			sprintf(output, "keyset-%s", namestr);
-		}
-
-		if (dst_key_iszonekey(key)) {
-			dst_key_t *zonekey = NULL;
-			result = dst_key_fromnamedfile(argv[i],
-						       DST_TYPE_PUBLIC |
-						       DST_TYPE_PRIVATE,
-						       mctx, &zonekey);
-			if (result != ISC_R_SUCCESS)
-				fatal("failed to read private key %s: %s",
-				      argv[i], isc_result_totext(result));
-			if (!zonekey_on_list(zonekey)) {
-				keynode = isc_mem_get(mctx, sizeof(keynode_t));
-				if (keynode == NULL)
-					fatal("out of memory");
-				keynode->key = zonekey;
-				ISC_LIST_INITANDAPPEND(keylist, keynode, link);
-			} else
-				dst_key_free(&zonekey);
-		}
-		dns_rdata_reset(&rdata);
-		isc_buffer_init(&b, data, sizeof(data));
-		result = dst_key_todns(key, &b);
-		dst_key_free(&key);
-		if (result != ISC_R_SUCCESS)
-			fatal("failed to convert key %s to a DNS KEY: %s",
-			      argv[i], isc_result_totext(result));
-		isc_buffer_usedregion(&b, &r);
-		dns_rdata_fromregion(&rdata, rdclass, dns_rdatatype_dnskey, &r);
-		tuple = NULL;
-		result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD,
-					      domain, ttl, &rdata, &tuple);
-		check_result(result, "dns_difftuple_create");
-		dns_diff_append(&diff, &tuple);
-	}
-
-	db = NULL;
-	result = dns_db_create(mctx, "rbt", dns_rootname, dns_dbtype_zone,
-			       rdclass, 0, NULL, &db);
-	if (result != ISC_R_SUCCESS)
-		fatal("failed to create a database");
-
-	version = NULL;
-	dns_db_newversion(db, &version);
-
-	result = dns_diff_apply(&diff, db, version);
-	check_result(result, "dns_diff_apply");
-	dns_diff_clear(&diff);
-
-	dns_fixedname_init(&tname);
-	dns_rdataset_init(&rdataset);
-	result = dns_db_find(db, domain, version, dns_rdatatype_dnskey, 0, 0,
-			     NULL, dns_fixedname_name(&tname), &rdataset,
-			     NULL);
-	check_result(result, "dns_db_find");
-
-	if (ISC_LIST_EMPTY(keylist))
-		fprintf(stderr,
-			"%s: no private zone key found; not self-signing\n",
-			program);
-	for (keynode = ISC_LIST_HEAD(keylist);
-	     keynode != NULL;
-	     keynode = ISC_LIST_NEXT(keynode, link))
-	{
-		dns_rdata_reset(&rdata);
-		isc_buffer_init(&b, data, sizeof(data));
-		result = dns_dnssec_sign(domain, &rdataset, keynode->key,
-					 &starttime, &endtime, mctx, &b,
-					 &rdata);
-		isc_entropy_stopcallbacksources(ectx);
-		if (result != ISC_R_SUCCESS) {
-			char keystr[KEY_FORMATSIZE];
-			key_format(keynode->key, keystr, sizeof(keystr));
-			fatal("failed to sign keyset with key %s: %s",
-			      keystr, isc_result_totext(result));
-		}
-		if (tryverify) {
-			result = dns_dnssec_verify(domain, &rdataset,
-						   keynode->key, ISC_TRUE,
-						   mctx, &rdata);
-			if (result != ISC_R_SUCCESS) {
-				char keystr[KEY_FORMATSIZE];
-				key_format(keynode->key, keystr, sizeof(keystr));
-				fatal("signature from key '%s' failed to "
-				      "verify: %s",
-				      keystr, isc_result_totext(result));
-			}
-		}
-		tuple = NULL;
-		result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD,
-					      domain, ttl, &rdata, &tuple);
-		check_result(result, "dns_difftuple_create");
-		dns_diff_append(&diff, &tuple);
-	}
-
-	result = dns_diff_apply(&diff, db, version);
-	check_result(result, "dns_diff_apply");
-	dns_diff_clear(&diff);
-
-	dns_rdataset_disassociate(&rdataset);
-
-	dns_db_closeversion(db, &version, ISC_TRUE);
-	result = dns_db_dump(db, version, output);
-	if (result != ISC_R_SUCCESS) {
-		char domainstr[DNS_NAME_FORMATSIZE];
-		dns_name_format(domain, domainstr, sizeof(domainstr));
-		fatal("failed to write database for %s to %s",
-		      domainstr, output);
-	}
-
-	printf("%s\n", output);
-
-	dns_db_detach(&db);
-
-	while (!ISC_LIST_EMPTY(keylist)) {
-		keynode = ISC_LIST_HEAD(keylist);
-		ISC_LIST_UNLINK(keylist, keynode, link);
-		dst_key_free(&keynode->key);
-		isc_mem_put(mctx, keynode, sizeof(keynode_t));
-	}
-
-	cleanup_logging(&log);
-	cleanup_entropy(&ectx);
-
-	isc_mem_free(mctx, output);
-	dst_lib_destroy();
-	if (verbose > 10)
-		isc_mem_stats(mctx, stdout);
-	isc_mem_destroy(&mctx);
-	return (0);
-}
diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook b/contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook
deleted file mode 100644
index 07327481550b..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook
+++ /dev/null
@@ -1,233 +0,0 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
-<!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-
-<!-- $Id: dnssec-makekeyset.docbook,v 1.2.2.3.4.2 2004/06/03 02:24:55 marka Exp $ -->
-
-<refentry>
-  <refentryinfo>
-    <date>June 30, 2000</date>
-  </refentryinfo>
-
-  <refmeta>
-    <refentrytitle><application>dnssec-makekeyset</application></refentrytitle>
-    <manvolnum>8</manvolnum>
-    <refmiscinfo>BIND9</refmiscinfo>
-  </refmeta>
-
-  <refnamediv>
-    <refname><application>dnssec-makekeyset</application></refname>
-    <refpurpose>DNSSEC zone signing tool</refpurpose>
-  </refnamediv>
-
-  <refsynopsisdiv>
-    <cmdsynopsis>
-      <command>dnssec-makekeyset</command>
-      <arg><option>-a</option></arg>
-      <arg><option>-s <replaceable class="parameter">start-time</replaceable></option></arg>
-      <arg><option>-e <replaceable class="parameter">end-time</replaceable></option></arg>
-      <arg><option>-h</option></arg>
-      <arg><option>-p</option></arg>
-      <arg><option>-r <replaceable class="parameter">randomdev</replaceable></option></arg>
-      <arg><option>-t</option><replaceable class="parameter">ttl</replaceable></arg>
-      <arg><option>-v <replaceable class="parameter">level</replaceable></option></arg>
-      <arg choice="req" rep="repeat">key</arg>
-    </cmdsynopsis>
-  </refsynopsisdiv>
-
-  <refsect1>
-    <title>DESCRIPTION</title>
-    <para>
-        <command>dnssec-makekeyset</command> generates a key set from one
-	or more keys created by <command>dnssec-keygen</command>.  It creates
-	a file containing a KEY record for each key, and self-signs the key
-	set with each zone key.  The output file is of the form
-	<filename>keyset-nnnn.</filename>, where <filename>nnnn</filename>
-	is the zone name.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>OPTIONS</title>
-
-    <variablelist>
-      <varlistentry>
-        <term>-a</term>
-	<listitem>
-	  <para>
-	      Verify all generated signatures.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-s <replaceable class="parameter">start-time</replaceable></term>
-	<listitem>
-	  <para>
-	       Specify the date and time when the generated SIG records
-	       become valid.  This can be either an absolute or relative
-	       time.  An absolute start time is indicated by a number
-	       in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-	       14:45:00 UTC on May 30th, 2000.  A relative start time is
-	       indicated by +N, which is N seconds from the current time.
-	       If no <option>start-time</option> is specified, the current
-	       time is used.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-e <replaceable class="parameter">end-time</replaceable></term>
-	<listitem>
-	  <para>
-	       Specify the date and time when the generated SIG records
-	       expire.  As with <option>start-time</option>, an absolute
-	       time is indicated in YYYYMMDDHHMMSS notation.  A time relative
-	       to the start time is indicated with +N, which is N seconds from
-	       the start time.  A time relative to the current time is
-	       indicated with now+N.  If no <option>end-time</option> is
-	       specified, 30 days from the start time is used as a default.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-h</term>
-	<listitem>
-	  <para>
-	       Prints a short summary of the options and arguments to
-	       <command>dnssec-makekeyset</command>.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-p</term>
-	<listitem>
-	  <para>
-	       Use pseudo-random data when signing the zone.  This is faster,
-	       but less secure, than using real random data.  This option
-	       may be useful when signing large zones or when the entropy
-	       source is limited.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-r <replaceable class="parameter">randomdev</replaceable></term>
-	<listitem>
-	  <para>
-	       Specifies the source of randomness.  If the operating
-	       system does not provide a <filename>/dev/random</filename>
-	       or equivalent device, the default source of randomness
-	       is keyboard input.  <filename>randomdev</filename> specifies
-	       the name of a character device or file containing random
-	       data to be used instead of the default.  The special value
-	       <filename>keyboard</filename> indicates that keyboard
-	       input should be used.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-t <replaceable class="parameter">ttl</replaceable></term>
-	<listitem>
-	  <para>
-	       Specify the TTL (time to live) of the KEY and SIG records.
-	       The default is 3600 seconds.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-v <replaceable class="parameter">level</replaceable></term>
-	<listitem>
-	  <para>
-	       Sets the debugging level.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>key</term>
-	<listitem>
-	  <para>
-	       The list of keys to be included in the keyset file.  These keys
-	       are expressed in the form <filename>Knnnn.+aaa+iiiii</filename>
-	       as generated by <command>dnssec-keygen</command>.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-    </variablelist>
-  </refsect1>
-
-  <refsect1>
-    <title>EXAMPLE</title>
-    <para>
-        The following command generates a keyset containing the DSA key for
-	<userinput>example.com</userinput> generated in the
-	<command>dnssec-keygen</command> man page.
-    </para>
-    <para>
-        <userinput>dnssec-makekeyset -t 86400 -s 20000701120000 -e +2592000 Kexample.com.+003+26160</userinput>
-    </para>
-    <para>
-        In this example, <command>dnssec-makekeyset</command> creates
-	the file <filename>keyset-example.com.</filename>.  This file
-	contains the specified key and a self-generated signature.
-    </para>
-    <para>
-        The DNS administrator for <userinput>example.com</userinput> could
-	send <filename>keyset-example.com.</filename> to the DNS
-	administrator for <userinput>.com</userinput> for signing, if the
-	.com zone is DNSSEC-aware and the administrators of the two zones
-	have some mechanism for authenticating each other and exchanging
-	the keys and signatures securely.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>SEE ALSO</title>
-    <para>
-      <citerefentry>
-        <refentrytitle>dnssec-keygen</refentrytitle>
-	<manvolnum>8</manvolnum>
-      </citerefentry>,
-      <citerefentry>
-        <refentrytitle>dnssec-signkey</refentrytitle>
-	<manvolnum>8</manvolnum>
-      </citerefentry>,
-      <citetitle>BIND 9 Administrator Reference Manual</citetitle>,
-      <citetitle>RFC 2535</citetitle>.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>AUTHOR</title>
-    <para>
-        <corpauthor>Internet Systems Consortium</corpauthor>
-    </para>
-  </refsect1>
-
-</refentry>
-
-<!--
- - Local variables:
- - mode: sgml
- - End:
--->
diff --git a/contrib/bind9/bin/dnssec/dnssec-makekeyset.html b/contrib/bind9/bin/dnssec/dnssec-makekeyset.html
deleted file mode 100644
index 48f1d4a59e11..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-makekeyset.html
+++ /dev/null
@@ -1,407 +0,0 @@
-<!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-
-<!-- $Id: dnssec-makekeyset.html,v 1.4.2.2.4.1 2004/03/06 10:21:15 marka Exp $ -->
-
-<HTML
-><HEAD
-><TITLE
->dnssec-makekeyset</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-><SPAN
-CLASS="APPLICATION"
->dnssec-makekeyset</SPAN
-></A
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->dnssec-makekeyset</SPAN
->&nbsp;--&nbsp;DNSSEC zone signing tool</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->dnssec-makekeyset</B
->  [<TT
-CLASS="OPTION"
->-a</TT
->] [<TT
-CLASS="OPTION"
->-s <TT
-CLASS="REPLACEABLE"
-><I
->start-time</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-e <TT
-CLASS="REPLACEABLE"
-><I
->end-time</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-h</TT
->] [<TT
-CLASS="OPTION"
->-p</TT
->] [<TT
-CLASS="OPTION"
->-r <TT
-CLASS="REPLACEABLE"
-><I
->randomdev</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-t</TT
-><TT
-CLASS="REPLACEABLE"
-><I
->ttl</I
-></TT
->] [<TT
-CLASS="OPTION"
->-v <TT
-CLASS="REPLACEABLE"
-><I
->level</I
-></TT
-></TT
->] {key...}</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN38"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
-> generates a key set from one
-	or more keys created by <B
-CLASS="COMMAND"
->dnssec-keygen</B
->.  It creates
-	a file containing a KEY record for each key, and self-signs the key
-	set with each zone key.  The output file is of the form
-	<TT
-CLASS="FILENAME"
->keyset-nnnn.</TT
->, where <TT
-CLASS="FILENAME"
->nnnn</TT
->
-	is the zone name.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN45"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-a</DT
-><DD
-><P
->	      Verify all generated signatures.
-	  </P
-></DD
-><DT
->-s <TT
-CLASS="REPLACEABLE"
-><I
->start-time</I
-></TT
-></DT
-><DD
-><P
->	       Specify the date and time when the generated SIG records
-	       become valid.  This can be either an absolute or relative
-	       time.  An absolute start time is indicated by a number
-	       in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-	       14:45:00 UTC on May 30th, 2000.  A relative start time is
-	       indicated by +N, which is N seconds from the current time.
-	       If no <TT
-CLASS="OPTION"
->start-time</TT
-> is specified, the current
-	       time is used.
-	  </P
-></DD
-><DT
->-e <TT
-CLASS="REPLACEABLE"
-><I
->end-time</I
-></TT
-></DT
-><DD
-><P
->	       Specify the date and time when the generated SIG records
-	       expire.  As with <TT
-CLASS="OPTION"
->start-time</TT
->, an absolute
-	       time is indicated in YYYYMMDDHHMMSS notation.  A time relative
-	       to the start time is indicated with +N, which is N seconds from
-	       the start time.  A time relative to the current time is
-	       indicated with now+N.  If no <TT
-CLASS="OPTION"
->end-time</TT
-> is
-	       specified, 30 days from the start time is used as a default.
-	  </P
-></DD
-><DT
->-h</DT
-><DD
-><P
->	       Prints a short summary of the options and arguments to
-	       <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
->.
-	  </P
-></DD
-><DT
->-p</DT
-><DD
-><P
->	       Use pseudo-random data when signing the zone.  This is faster,
-	       but less secure, than using real random data.  This option
-	       may be useful when signing large zones or when the entropy
-	       source is limited.
-	  </P
-></DD
-><DT
->-r <TT
-CLASS="REPLACEABLE"
-><I
->randomdev</I
-></TT
-></DT
-><DD
-><P
->	       Specifies the source of randomness.  If the operating
-	       system does not provide a <TT
-CLASS="FILENAME"
->/dev/random</TT
->
-	       or equivalent device, the default source of randomness
-	       is keyboard input.  <TT
-CLASS="FILENAME"
->randomdev</TT
-> specifies
-	       the name of a character device or file containing random
-	       data to be used instead of the default.  The special value
-	       <TT
-CLASS="FILENAME"
->keyboard</TT
-> indicates that keyboard
-	       input should be used.
-	  </P
-></DD
-><DT
->-t <TT
-CLASS="REPLACEABLE"
-><I
->ttl</I
-></TT
-></DT
-><DD
-><P
->	       Specify the TTL (time to live) of the KEY and SIG records.
-	       The default is 3600 seconds.
-	  </P
-></DD
-><DT
->-v <TT
-CLASS="REPLACEABLE"
-><I
->level</I
-></TT
-></DT
-><DD
-><P
->	       Sets the debugging level.
-	  </P
-></DD
-><DT
->key</DT
-><DD
-><P
->	       The list of keys to be included in the keyset file.  These keys
-	       are expressed in the form <TT
-CLASS="FILENAME"
->Knnnn.+aaa+iiiii</TT
->
-	       as generated by <B
-CLASS="COMMAND"
->dnssec-keygen</B
->.
-	  </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN98"
-></A
-><H2
->EXAMPLE</H2
-><P
->        The following command generates a keyset containing the DSA key for
-	<TT
-CLASS="USERINPUT"
-><B
->example.com</B
-></TT
-> generated in the
-	<B
-CLASS="COMMAND"
->dnssec-keygen</B
-> man page.
-    </P
-><P
->        <TT
-CLASS="USERINPUT"
-><B
->dnssec-makekeyset -t 86400 -s 20000701120000 -e +2592000 Kexample.com.+003+26160</B
-></TT
->
-    </P
-><P
->        In this example, <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
-> creates
-	the file <TT
-CLASS="FILENAME"
->keyset-example.com.</TT
->.  This file
-	contains the specified key and a self-generated signature.
-    </P
-><P
->        The DNS administrator for <TT
-CLASS="USERINPUT"
-><B
->example.com</B
-></TT
-> could
-	send <TT
-CLASS="FILENAME"
->keyset-example.com.</TT
-> to the DNS
-	administrator for <TT
-CLASS="USERINPUT"
-><B
->.com</B
-></TT
-> for signing, if the
-	.com zone is DNSSEC-aware and the administrators of the two zones
-	have some mechanism for authenticating each other and exchanging
-	the keys and signatures securely.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN112"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-keygen</SPAN
->(8)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-signkey</SPAN
->(8)</SPAN
->,
-      <I
-CLASS="CITETITLE"
->BIND 9 Administrator Reference Manual</I
->,
-      <I
-CLASS="CITETITLE"
->RFC 2535</I
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN123"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Software Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.8 b/contrib/bind9/bin/dnssec/dnssec-signkey.8
deleted file mode 100644
index ea2818bdfe21..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-signkey.8
+++ /dev/null
@@ -1,108 +0,0 @@
-.\" Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
-.\"
-.\" Permission to use, copy, modify, and distribute this software for any
-.\" purpose with or without fee is hereby granted, provided that the above
-.\" copyright notice and this permission notice appear in all copies.
-.\"
-.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-.\" REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-.\" AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-.\" INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-.\" LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-.\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-.\" PERFORMANCE OF THIS SOFTWARE.
-.\"
-.\" $Id: dnssec-signkey.8,v 1.18.2.1.4.1 2004/03/06 07:41:39 marka Exp $
-.\"
-.TH "DNSSEC-SIGNKEY" "8" "June 30, 2000" "BIND9" ""
-.SH NAME
-dnssec-signkey \- DNSSEC key set signing tool
-.SH SYNOPSIS
-.sp
-\fBdnssec-signkey\fR [ \fB-a\fR ]  [ \fB-c \fIclass\fB\fR ]  [ \fB-s \fIstart-time\fB\fR ]  [ \fB-e \fIend-time\fB\fR ]  [ \fB-h\fR ]  [ \fB-p\fR ]  [ \fB-r \fIrandomdev\fB\fR ]  [ \fB-v \fIlevel\fB\fR ]  \fBkeyset\fR \fBkey\fR\fI...\fR
-.SH "DESCRIPTION"
-.PP
-\fBdnssec-signkey\fR signs a keyset. Typically
-the keyset will be for a child zone, and will have been generated
-by \fBdnssec-makekeyset\fR. The child zone's keyset
-is signed with the zone keys for its parent zone. The output file
-is of the form \fIsignedkey-nnnn.\fR, where
-\fInnnn\fR is the zone name.
-.SH "OPTIONS"
-.TP
-\fB-a\fR
-Verify all generated signatures.
-.TP
-\fB-c \fIclass\fB\fR
-Specifies the DNS class of the key sets.
-.TP
-\fB-s \fIstart-time\fB\fR
-Specify the date and time when the generated SIG records
-become valid. This can be either an absolute or relative
-time. An absolute start time is indicated by a number
-in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-14:45:00 UTC on May 30th, 2000. A relative start time is
-indicated by +N, which is N seconds from the current time.
-If no \fBstart-time\fR is specified, the current
-time is used.
-.TP
-\fB-e \fIend-time\fB\fR
-Specify the date and time when the generated SIG records
-expire. As with \fBstart-time\fR, an absolute
-time is indicated in YYYYMMDDHHMMSS notation. A time relative
-to the start time is indicated with +N, which is N seconds from
-the start time. A time relative to the current time is
-indicated with now+N. If no \fBend-time\fR is
-specified, 30 days from the start time is used as a default.
-.TP
-\fB-h\fR
-Prints a short summary of the options and arguments to
-\fBdnssec-signkey\fR.
-.TP
-\fB-p\fR
-Use pseudo-random data when signing the zone. This is faster,
-but less secure, than using real random data. This option
-may be useful when signing large zones or when the entropy
-source is limited.
-.TP
-\fB-r \fIrandomdev\fB\fR
-Specifies the source of randomness. If the operating
-system does not provide a \fI/dev/random\fR
-or equivalent device, the default source of randomness
-is keyboard input. \fIrandomdev\fR specifies
-the name of a character device or file containing random
-data to be used instead of the default. The special value
-\fIkeyboard\fR indicates that keyboard
-input should be used.
-.TP
-\fB-v \fIlevel\fB\fR
-Sets the debugging level.
-.TP
-\fBkeyset\fR
-The file containing the child's keyset.
-.TP
-\fBkey\fR
-The keys used to sign the child's keyset.
-.SH "EXAMPLE"
-.PP
-The DNS administrator for a DNSSEC-aware \fB.com\fR
-zone would use the following command to sign the
-\fIkeyset\fR file for \fBexample.com\fR
-created by \fBdnssec-makekeyset\fR with a key generated
-by \fBdnssec-keygen\fR:
-.PP
-\fBdnssec-signkey keyset-example.com. Kcom.+003+51944\fR
-.PP
-In this example, \fBdnssec-signkey\fR creates
-the file \fIsignedkey-example.com.\fR, which
-contains the \fBexample.com\fR keys and the
-signatures by the \fB.com\fR keys.
-.SH "SEE ALSO"
-.PP
-\fBdnssec-keygen\fR(8),
-\fBdnssec-makekeyset\fR(8),
-\fBdnssec-signzone\fR(8).
-.SH "AUTHOR"
-.PP
-Internet Software Consortium
diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.c b/contrib/bind9/bin/dnssec/dnssec-signkey.c
deleted file mode 100644
index fd8b0fd322b5..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-signkey.c
+++ /dev/null
@@ -1,448 +0,0 @@
-/*
- * Portions Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright (C) 2000-2003  Internet Software Consortium.
- * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
- *
- * Permission to use, copy, modify, and distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND ISC AND NETWORK ASSOCIATES DISCLAIMS
- * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE
- * FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR
- * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-/* $Id: dnssec-signkey.c,v 1.50.2.2.2.7 2004/08/28 06:25:28 marka Exp $ */
-
-#include <config.h>
-
-#include <stdlib.h>
-
-#include <isc/string.h>
-#include <isc/commandline.h>
-#include <isc/entropy.h>
-#include <isc/mem.h>
-#include <isc/print.h>
-#include <isc/util.h>
-
-#include <dns/db.h>
-#include <dns/dbiterator.h>
-#include <dns/diff.h>
-#include <dns/dnssec.h>
-#include <dns/fixedname.h>
-#include <dns/log.h>
-#include <dns/rdata.h>
-#include <dns/rdataclass.h>
-#include <dns/rdataset.h>
-#include <dns/rdatasetiter.h>
-#include <dns/rdatastruct.h>
-#include <dns/result.h>
-#include <dns/secalg.h>
-
-#include <dst/dst.h>
-
-#include "dnssectool.h"
-
-const char *program = "dnssec-signkey";
-int verbose;
-
-typedef struct keynode keynode_t;
-struct keynode {
-	dst_key_t *key;
-	isc_boolean_t verified;
-	ISC_LINK(keynode_t) link;
-};
-typedef ISC_LIST(keynode_t) keylist_t;
-
-static isc_stdtime_t starttime = 0, endtime = 0, now;
-
-static isc_mem_t *mctx = NULL;
-static isc_entropy_t *ectx = NULL;
-static keylist_t keylist;
-
-static void
-usage(void) {
-	fprintf(stderr, "Usage:\n");
-	fprintf(stderr, "\t%s [options] keyset keys\n", program);
-
-	fprintf(stderr, "\n");
-
-	fprintf(stderr, "Version: %s\n", VERSION);
-
-	fprintf(stderr, "Options: (default value in parenthesis) \n");
-	fprintf(stderr, "\t-a\n");
-	fprintf(stderr, "\t\tverify generated signatures\n");
-	fprintf(stderr, "\t-c class (IN)\n");
-	fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n");
-	fprintf(stderr, "\t\tSIG start time - absolute|offset (from keyset)\n");
-	fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n");
-	fprintf(stderr, "\t\tSIG end time  - absolute|from start|from now "
-		"(from keyset)\n");
-	fprintf(stderr, "\t-v level:\n");
-	fprintf(stderr, "\t\tverbose level (0)\n");
-	fprintf(stderr, "\t-p\n");
-	fprintf(stderr, "\t\tuse pseudorandom data (faster but less secure)\n");
-	fprintf(stderr, "\t-r randomdev:\n");
-	fprintf(stderr, "\t\ta file containing random data\n");
-
-	fprintf(stderr, "\n");
-
-	fprintf(stderr, "keyset:\n");
-	fprintf(stderr, "\tfile with keyset to be signed (keyset-<name>)\n");
-	fprintf(stderr, "keys:\n");
-	fprintf(stderr, "\tkeyfile (Kname+alg+tag)\n");
-
-	fprintf(stderr, "\n");
-	fprintf(stderr, "Output:\n");
-	fprintf(stderr, "\tsigned keyset (signedkey-<name>)\n");
-	exit(0);
-}
-
-static void
-loadkeys(dns_name_t *name, dns_rdataset_t *rdataset) {
-	dst_key_t *key;
-	dns_rdata_t rdata = DNS_RDATA_INIT;
-	keynode_t *keynode;
-	isc_result_t result;
-
-	ISC_LIST_INIT(keylist);
-	result = dns_rdataset_first(rdataset);
-	check_result(result, "dns_rdataset_first");
-	for (; result == ISC_R_SUCCESS; result = dns_rdataset_next(rdataset)) {
-		dns_rdata_reset(&rdata);
-		dns_rdataset_current(rdataset, &rdata);
-		key = NULL;
-		result = dns_dnssec_keyfromrdata(name, &rdata, mctx, &key);
-		if (result != ISC_R_SUCCESS)
-			continue;
-		if (!dst_key_iszonekey(key)) {
-			dst_key_free(&key);
-			continue;
-		}
-		keynode = isc_mem_get(mctx, sizeof(keynode_t));
-		if (keynode == NULL)
-			fatal("out of memory");
-		keynode->key = key;
-		keynode->verified = ISC_FALSE;
-		ISC_LIST_INITANDAPPEND(keylist, keynode, link);
-	}
-	if (result != ISC_R_NOMORE)
-		fatal("failure traversing key list");
-}
-
-static dst_key_t *
-findkey(dns_rdata_rrsig_t *sig) {
-	keynode_t *keynode;
-	for (keynode = ISC_LIST_HEAD(keylist);
-	     keynode != NULL;
-	     keynode = ISC_LIST_NEXT(keynode, link))
-	{
-		if (dst_key_id(keynode->key) == sig->keyid &&
-		    dst_key_alg(keynode->key) == sig->algorithm) {
-			keynode->verified = ISC_TRUE;
-			return (keynode->key);
-		}
-	}
-	fatal("signature generated by non-zone or missing key");
-	return (NULL);
-}
-
-int
-main(int argc, char *argv[]) {
-	int i, ch;
-	char *startstr = NULL, *endstr = NULL, *classname = NULL;
-	char tdomain[1025];
-	dns_fixedname_t fdomain;
-	dns_name_t *domain;
-	char *output = NULL;
-	char *endp;
-	unsigned char data[65536];
-	dns_db_t *db;
-	dns_dbnode_t *node;
-	dns_dbversion_t *version;
-	dns_diff_t diff;
-	dns_difftuple_t *tuple;
-	dns_dbiterator_t *dbiter;
-	dns_rdatasetiter_t *rdsiter;
-	dst_key_t *key = NULL;
-	dns_rdata_t rdata = DNS_RDATA_INIT;
-	dns_rdata_t sigrdata = DNS_RDATA_INIT;
-	dns_rdataset_t rdataset, sigrdataset;
-	dns_rdata_rrsig_t sig;
-	isc_result_t result;
-	isc_buffer_t b;
-	isc_log_t *log = NULL;
-	keynode_t *keynode;
-	isc_boolean_t pseudorandom = ISC_FALSE;
-	unsigned int eflags;
-	dns_rdataclass_t rdclass;
-	isc_boolean_t tryverify = ISC_FALSE;
-	isc_boolean_t settime = ISC_FALSE;
-
-	result = isc_mem_create(0, 0, &mctx);
-	check_result(result, "isc_mem_create()");
-
-	dns_result_register();
-
-	while ((ch = isc_commandline_parse(argc, argv, "ac:s:e:pr:v:h")) != -1)
-	{
-		switch (ch) {
-		case 'a':
-			tryverify = ISC_TRUE;
-			break;
-		case 'c':
-			classname = isc_commandline_argument;
-			break;
-
-		case 's':
-			startstr = isc_commandline_argument;
-			break;
-						
-		case 'e':
-			endstr = isc_commandline_argument;
-			break;
-
-		case 'p':
-			pseudorandom = ISC_TRUE;
-			break;
-
-		case 'r':
-			setup_entropy(mctx, isc_commandline_argument, &ectx);
-			break;
-
-		case 'v':
-			endp = NULL;
-			verbose = strtol(isc_commandline_argument, &endp, 0);
-			if (*endp != '\0')
-				fatal("verbose level must be numeric");
-			break;
-
-		case 'h':
-		default:
-			usage();
-
-		}
-	}
-
-	argc -= isc_commandline_index;
-	argv += isc_commandline_index;
-
-	if (argc < 2)
-		usage();
-
-	rdclass = strtoclass(classname);
-
-	if (ectx == NULL)
-		setup_entropy(mctx, NULL, &ectx);
-	eflags = ISC_ENTROPY_BLOCKING;
-	if (!pseudorandom)
-		eflags |= ISC_ENTROPY_GOODONLY;
-	result = dst_lib_init(mctx, ectx, eflags);
-	if (result != ISC_R_SUCCESS)
-		fatal("could not initialize dst: %s", 
-		      isc_result_totext(result));
-
-	isc_stdtime_get(&now);
-
-	if ((startstr == NULL || endstr == NULL) &&
-	    !(startstr == NULL && endstr == NULL))
-		fatal("if -s or -e is specified, both must be");
-
-	if (startstr != NULL) {
-		starttime = strtotime(startstr, now, now);
-		endtime = strtotime(endstr, now, starttime);
-		settime = ISC_TRUE;
-	}
-
-	setup_logging(verbose, mctx, &log);
-
-	if (strlen(argv[0]) < 8U || strncmp(argv[0], "keyset-", 7) != 0)
-		fatal("keyset file '%s' must start with keyset-", argv[0]);
-
-	db = NULL;
-	result = dns_db_create(mctx, "rbt", dns_rootname, dns_dbtype_zone,
-			       rdclass, 0, NULL, &db);
-	check_result(result, "dns_db_create()");
-
-	result = dns_db_load(db, argv[0]);
-	if (result != ISC_R_SUCCESS && result != DNS_R_SEENINCLUDE)
-		fatal("failed to load database from '%s': %s", argv[0],
-		      isc_result_totext(result));
-
-	dns_fixedname_init(&fdomain);
-	domain = dns_fixedname_name(&fdomain);
-
-	dbiter = NULL;
-	result = dns_db_createiterator(db, ISC_FALSE, &dbiter);
-	check_result(result, "dns_db_createiterator()");
-
-	result = dns_dbiterator_first(dbiter);
-	check_result(result, "dns_dbiterator_first()");
-	while (result == ISC_R_SUCCESS) {
-		node = NULL;
-		dns_dbiterator_current(dbiter, &node, domain);
-		rdsiter = NULL;
-		result = dns_db_allrdatasets(db, node, NULL, 0, &rdsiter);
-		check_result(result, "dns_db_allrdatasets()");
-		result = dns_rdatasetiter_first(rdsiter);
-		dns_rdatasetiter_destroy(&rdsiter);
-		if (result == ISC_R_SUCCESS)
-			break;
-		dns_db_detachnode(db, &node);
-		result = dns_dbiterator_next(dbiter);
-	}
-	dns_dbiterator_destroy(&dbiter);
-	if (result != ISC_R_SUCCESS)
-		fatal("failed to find data in keyset file");
-
-	isc_buffer_init(&b, tdomain, sizeof(tdomain) - 1);
-	result = dns_name_tofilenametext(domain, ISC_FALSE, &b);
-	check_result(result, "dns_name_tofilenametext()");
-	isc_buffer_putuint8(&b, 0);
-
-	output = isc_mem_allocate(mctx,
-				  strlen("signedkey-") + strlen(tdomain) + 1);
-	if (output == NULL)
-		fatal("out of memory");
-	sprintf(output, "signedkey-%s", tdomain);
-
-	version = NULL;
-	dns_db_newversion(db, &version);
-
-	dns_rdataset_init(&rdataset);
-	dns_rdataset_init(&sigrdataset);
-	result = dns_db_findrdataset(db, node, version, dns_rdatatype_dnskey, 0,
-				     0, &rdataset, &sigrdataset);
-	if (result != ISC_R_SUCCESS) {
-		char domainstr[DNS_NAME_FORMATSIZE];
-		dns_name_format(domain, domainstr, sizeof(domainstr));
-		fatal("failed to find rdataset '%s KEY': %s",
-		      domainstr, isc_result_totext(result));
-	}
-
-	loadkeys(domain, &rdataset);
-
-	dns_diff_init(mctx, &diff);
-
-	if (!dns_rdataset_isassociated(&sigrdataset))
-		fatal("no SIG KEY set present");
-
-	result = dns_rdataset_first(&sigrdataset);
-	check_result(result, "dns_rdataset_first()");
-	do {
-		dns_rdataset_current(&sigrdataset, &sigrdata);
-		result = dns_rdata_tostruct(&sigrdata, &sig, mctx);
-		check_result(result, "dns_rdata_tostruct()");
-		key = findkey(&sig);
-		result = dns_dnssec_verify(domain, &rdataset, key,
-					   ISC_TRUE, mctx, &sigrdata);
-		if (result != ISC_R_SUCCESS) {
-			char keystr[KEY_FORMATSIZE];
-			key_format(key, keystr, sizeof(keystr));
-			fatal("signature by key '%s' did not verify: %s",
-			      keystr, isc_result_totext(result));
-		}
-		if (!settime) {
-			starttime = sig.timesigned;
-			endtime = sig.timeexpire;
-			settime = ISC_TRUE;
-		}
-		dns_rdata_freestruct(&sig);
-		dns_rdata_reset(&sigrdata);
-		result = dns_rdataset_next(&sigrdataset);
-	} while (result == ISC_R_SUCCESS);
-
-	for (keynode = ISC_LIST_HEAD(keylist);
-	     keynode != NULL;
-	     keynode = ISC_LIST_NEXT(keynode, link))
-		if (!keynode->verified)
-			fatal("not all zone keys self signed the key set");
-
-	argc -= 1;
-	argv += 1;
-
-	for (i = 0; i < argc; i++) {
-		key = NULL;
-		result = dst_key_fromnamedfile(argv[i],
-					       DST_TYPE_PUBLIC |
-					       DST_TYPE_PRIVATE,
-					       mctx, &key);
-		if (result != ISC_R_SUCCESS)
-			fatal("failed to read key %s from disk: %s",
-			      argv[i], isc_result_totext(result));
-
-		dns_rdata_reset(&rdata);
-		isc_buffer_init(&b, data, sizeof(data));
-		result = dns_dnssec_sign(domain, &rdataset, key,
-					 &starttime, &endtime,
-					 mctx, &b, &rdata);
-		isc_entropy_stopcallbacksources(ectx);
-		if (result != ISC_R_SUCCESS) {
-			char keystr[KEY_FORMATSIZE];
-			key_format(key, keystr, sizeof(keystr));
-			fatal("key '%s' failed to sign data: %s",
-			      keystr, isc_result_totext(result));
-		}
-		if (tryverify) {
-			result = dns_dnssec_verify(domain, &rdataset, key,
-						   ISC_TRUE, mctx, &rdata);
-			if (result != ISC_R_SUCCESS) {
-				char keystr[KEY_FORMATSIZE];
-				key_format(key, keystr, sizeof(keystr));
-				fatal("signature from key '%s' failed to "
-				      "verify: %s",
-				      keystr, isc_result_totext(result));
-			}
-		}
-		tuple = NULL;
-		result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD,
-					      domain, rdataset.ttl,
-					      &rdata, &tuple);
-		check_result(result, "dns_difftuple_create");
-		dns_diff_append(&diff, &tuple);
-		dst_key_free(&key);
-	}
-
-	result = dns_db_deleterdataset(db, node, version, dns_rdatatype_rrsig,
-				       dns_rdatatype_dnskey);
-	check_result(result, "dns_db_deleterdataset");
-
-	result = dns_diff_apply(&diff, db, version);
-	check_result(result, "dns_diff_apply");
-	dns_diff_clear(&diff);
-
-	dns_db_detachnode(db, &node);
-	dns_db_closeversion(db, &version, ISC_TRUE);
-	result = dns_db_dump(db, version, output);
-	if (result != ISC_R_SUCCESS)
-		fatal("failed to write database to '%s': %s",
-		      output, isc_result_totext(result));
-
-	printf("%s\n", output);
-
-	dns_rdataset_disassociate(&rdataset);
-	dns_rdataset_disassociate(&sigrdataset);
-
-	dns_db_detach(&db);
-
-	while (!ISC_LIST_EMPTY(keylist)) {
-		keynode = ISC_LIST_HEAD(keylist);
-		ISC_LIST_UNLINK(keylist, keynode, link);
-		dst_key_free(&keynode->key);
-		isc_mem_put(mctx, keynode, sizeof(keynode_t));
-	}
-
-	cleanup_logging(&log);
-
-	isc_mem_free(mctx, output);
-	cleanup_entropy(&ectx);
-	dst_lib_destroy();
-	if (verbose > 10)
-		isc_mem_stats(mctx, stdout);
-	isc_mem_destroy(&mctx);
-	return (0);
-}
diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.docbook b/contrib/bind9/bin/dnssec/dnssec-signkey.docbook
deleted file mode 100644
index 8258a3da7102..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-signkey.docbook
+++ /dev/null
@@ -1,237 +0,0 @@
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
-<!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-
-<!-- $Id: dnssec-signkey.docbook,v 1.2.2.2.4.2 2004/06/03 02:24:55 marka Exp $ -->
-
-<refentry>
-  <refentryinfo>
-    <date>June 30, 2000</date>
-  </refentryinfo>
-
-  <refmeta>
-    <refentrytitle><application>dnssec-signkey</application></refentrytitle>
-    <manvolnum>8</manvolnum>
-    <refmiscinfo>BIND9</refmiscinfo>
-  </refmeta>
-
-  <refnamediv>
-    <refname><application>dnssec-signkey</application></refname>
-    <refpurpose>DNSSEC key set signing tool</refpurpose>
-  </refnamediv>
-
-  <refsynopsisdiv>
-    <cmdsynopsis>
-      <command>dnssec-signkey</command>
-      <arg><option>-a</option></arg>
-      <arg><option>-c <replaceable class="parameter">class</replaceable></option></arg>
-      <arg><option>-s <replaceable class="parameter">start-time</replaceable></option></arg>
-      <arg><option>-e <replaceable class="parameter">end-time</replaceable></option></arg>
-      <arg><option>-h</option></arg>
-      <arg><option>-p</option></arg>
-      <arg><option>-r <replaceable class="parameter">randomdev</replaceable></option></arg>
-      <arg><option>-v <replaceable class="parameter">level</replaceable></option></arg>
-      <arg choice="req">keyset</arg>
-      <arg choice="req" rep="repeat">key</arg>
-    </cmdsynopsis>
-  </refsynopsisdiv>
-
-  <refsect1>
-    <title>DESCRIPTION</title>
-    <para>
-        <command>dnssec-signkey</command> signs a keyset.  Typically
-	the keyset will be for a child zone, and will have been generated
-	by <command>dnssec-makekeyset</command>.  The child zone's keyset
-	is signed with the zone keys for its parent zone.  The output file
-	is of the form <filename>signedkey-nnnn.</filename>, where
-	<filename>nnnn</filename> is the zone name.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>OPTIONS</title>
-
-    <variablelist>
-      <varlistentry>
-        <term>-a</term>
-	<listitem>
-	  <para>
-	      Verify all generated signatures.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-c <replaceable class="parameter">class</replaceable></term>
-	<listitem>
-	  <para>
-	       Specifies the DNS class of the key sets.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-s <replaceable class="parameter">start-time</replaceable></term>
-	<listitem>
-	  <para>
-	       Specify the date and time when the generated SIG records
-	       become valid.  This can be either an absolute or relative
-	       time.  An absolute start time is indicated by a number
-	       in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-	       14:45:00 UTC on May 30th, 2000.  A relative start time is
-	       indicated by +N, which is N seconds from the current time.
-	       If no <option>start-time</option> is specified, the current
-	       time is used.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-e <replaceable class="parameter">end-time</replaceable></term>
-	<listitem>
-	  <para>
-	       Specify the date and time when the generated SIG records
-	       expire.  As with <option>start-time</option>, an absolute
-	       time is indicated in YYYYMMDDHHMMSS notation.  A time relative
-	       to the start time is indicated with +N, which is N seconds from
-	       the start time.  A time relative to the current time is
-	       indicated with now+N.  If no <option>end-time</option> is
-	       specified, 30 days from the start time is used as a default.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-h</term>
-	<listitem>
-	  <para>
-	       Prints a short summary of the options and arguments to
-	       <command>dnssec-signkey</command>.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-p</term>
-	<listitem>
-	  <para>
-	       Use pseudo-random data when signing the zone.  This is faster,
-	       but less secure, than using real random data.  This option
-	       may be useful when signing large zones or when the entropy
-	       source is limited.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-r <replaceable class="parameter">randomdev</replaceable></term>
-	<listitem>
-	  <para>
-	       Specifies the source of randomness.  If the operating
-	       system does not provide a <filename>/dev/random</filename>
-	       or equivalent device, the default source of randomness
-	       is keyboard input.  <filename>randomdev</filename> specifies
-	       the name of a character device or file containing random
-	       data to be used instead of the default.  The special value
-	       <filename>keyboard</filename> indicates that keyboard
-	       input should be used.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>-v <replaceable class="parameter">level</replaceable></term>
-	<listitem>
-	  <para>
-	       Sets the debugging level.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>keyset</term>
-	  <listitem>
-	    <para>
-	        The file containing the child's keyset.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term>key</term>
-	  <listitem>
-	    <para>
-	        The keys used to sign the child's keyset.
-	  </para>
-	</listitem>
-      </varlistentry>
-
-    </variablelist>
-  </refsect1>
-
-  <refsect1>
-    <title>EXAMPLE</title>
-    <para>
-        The DNS administrator for a DNSSEC-aware <userinput>.com</userinput>
-	zone would use the following command to sign the
-	<filename>keyset</filename> file for <userinput>example.com</userinput>
-	created by <command>dnssec-makekeyset</command> with a key generated
-	by <command>dnssec-keygen</command>:
-    </para>
-    <para>
-        <userinput>dnssec-signkey keyset-example.com. Kcom.+003+51944</userinput>
-    </para>
-    <para>
-        In this example, <command>dnssec-signkey</command> creates
-	the file <filename>signedkey-example.com.</filename>, which
-	contains the <userinput>example.com</userinput> keys and the
-	signatures by the <userinput>.com</userinput> keys.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>SEE ALSO</title>
-    <para>
-      <citerefentry>
-        <refentrytitle>dnssec-keygen</refentrytitle>
-	<manvolnum>8</manvolnum>
-      </citerefentry>,
-      <citerefentry>
-        <refentrytitle>dnssec-makekeyset</refentrytitle>
-	<manvolnum>8</manvolnum>
-      </citerefentry>,
-      <citerefentry>
-        <refentrytitle>dnssec-signzone</refentrytitle>
-	<manvolnum>8</manvolnum>
-      </citerefentry>.
-    </para>
-  </refsect1>
-
-  <refsect1>
-    <title>AUTHOR</title>
-    <para>
-        <corpauthor>Internet Systems Consortium</corpauthor>
-    </para>
-  </refsect1>
-
-</refentry>
-
-<!--
- - Local variables:
- - mode: sgml
- - End:
--->
diff --git a/contrib/bind9/bin/dnssec/dnssec-signkey.html b/contrib/bind9/bin/dnssec/dnssec-signkey.html
deleted file mode 100644
index 8cbf1fc736a3..000000000000
--- a/contrib/bind9/bin/dnssec/dnssec-signkey.html
+++ /dev/null
@@ -1,407 +0,0 @@
-<!--
- - Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
- - Copyright (C) 2001, 2003  Internet Software Consortium.
- -
- - Permission to use, copy, modify, and distribute this software for any
- - purpose with or without fee is hereby granted, provided that the above
- - copyright notice and this permission notice appear in all copies.
- -
- - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- - PERFORMANCE OF THIS SOFTWARE.
--->
-
-<!-- $Id: dnssec-signkey.html,v 1.4.2.1.4.1 2004/03/06 10:21:15 marka Exp $ -->
-
-<HTML
-><HEAD
-><TITLE
->dnssec-signkey</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.73
-"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><H1
-><A
-NAME="AEN1"
-><SPAN
-CLASS="APPLICATION"
->dnssec-signkey</SPAN
-></A
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN9"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->dnssec-signkey</SPAN
->&nbsp;--&nbsp;DNSSEC key set signing tool</DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN13"
-></A
-><H2
->Synopsis</H2
-><P
-><B
-CLASS="COMMAND"
->dnssec-signkey</B
->  [<TT
-CLASS="OPTION"
->-a</TT
->] [<TT
-CLASS="OPTION"
->-c <TT
-CLASS="REPLACEABLE"
-><I
->class</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-s <TT
-CLASS="REPLACEABLE"
-><I
->start-time</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-e <TT
-CLASS="REPLACEABLE"
-><I
->end-time</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-h</TT
->] [<TT
-CLASS="OPTION"
->-p</TT
->] [<TT
-CLASS="OPTION"
->-r <TT
-CLASS="REPLACEABLE"
-><I
->randomdev</I
-></TT
-></TT
->] [<TT
-CLASS="OPTION"
->-v <TT
-CLASS="REPLACEABLE"
-><I
->level</I
-></TT
-></TT
->] {keyset} {key...}</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN39"
-></A
-><H2
->DESCRIPTION</H2
-><P
->        <B
-CLASS="COMMAND"
->dnssec-signkey</B
-> signs a keyset.  Typically
-	the keyset will be for a child zone, and will have been generated
-	by <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
->.  The child zone's keyset
-	is signed with the zone keys for its parent zone.  The output file
-	is of the form <TT
-CLASS="FILENAME"
->signedkey-nnnn.</TT
->, where
-	<TT
-CLASS="FILENAME"
->nnnn</TT
-> is the zone name.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN46"
-></A
-><H2
->OPTIONS</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
->-a</DT
-><DD
-><P
->	      Verify all generated signatures.
-	  </P
-></DD
-><DT
->-c <TT
-CLASS="REPLACEABLE"
-><I
->class</I
-></TT
-></DT
-><DD
-><P
->	       Specifies the DNS class of the key sets.
-	  </P
-></DD
-><DT
->-s <TT
-CLASS="REPLACEABLE"
-><I
->start-time</I
-></TT
-></DT
-><DD
-><P
->	       Specify the date and time when the generated SIG records
-	       become valid.  This can be either an absolute or relative
-	       time.  An absolute start time is indicated by a number
-	       in YYYYMMDDHHMMSS notation; 20000530144500 denotes
-	       14:45:00 UTC on May 30th, 2000.  A relative start time is
-	       indicated by +N, which is N seconds from the current time.
-	       If no <TT
-CLASS="OPTION"
->start-time</TT
-> is specified, the current
-	       time is used.
-	  </P
-></DD
-><DT
->-e <TT
-CLASS="REPLACEABLE"
-><I
->end-time</I
-></TT
-></DT
-><DD
-><P
->	       Specify the date and time when the generated SIG records
-	       expire.  As with <TT
-CLASS="OPTION"
->start-time</TT
->, an absolute
-	       time is indicated in YYYYMMDDHHMMSS notation.  A time relative
-	       to the start time is indicated with +N, which is N seconds from
-	       the start time.  A time relative to the current time is
-	       indicated with now+N.  If no <TT
-CLASS="OPTION"
->end-time</TT
-> is
-	       specified, 30 days from the start time is used as a default.
-	  </P
-></DD
-><DT
->-h</DT
-><DD
-><P
->	       Prints a short summary of the options and arguments to
-	       <B
-CLASS="COMMAND"
->dnssec-signkey</B
->.
-	  </P
-></DD
-><DT
->-p</DT
-><DD
-><P
->	       Use pseudo-random data when signing the zone.  This is faster,
-	       but less secure, than using real random data.  This option
-	       may be useful when signing large zones or when the entropy
-	       source is limited.
-	  </P
-></DD
-><DT
->-r <TT
-CLASS="REPLACEABLE"
-><I
->randomdev</I
-></TT
-></DT
-><DD
-><P
->	       Specifies the source of randomness.  If the operating
-	       system does not provide a <TT
-CLASS="FILENAME"
->/dev/random</TT
->
-	       or equivalent device, the default source of randomness
-	       is keyboard input.  <TT
-CLASS="FILENAME"
->randomdev</TT
-> specifies
-	       the name of a character device or file containing random
-	       data to be used instead of the default.  The special value
-	       <TT
-CLASS="FILENAME"
->keyboard</TT
-> indicates that keyboard
-	       input should be used.
-	  </P
-></DD
-><DT
->-v <TT
-CLASS="REPLACEABLE"
-><I
->level</I
-></TT
-></DT
-><DD
-><P
->	       Sets the debugging level.
-	  </P
-></DD
-><DT
->keyset</DT
-><DD
-><P
->	        The file containing the child's keyset.
-	  </P
-></DD
-><DT
->key</DT
-><DD
-><P
->	        The keys used to sign the child's keyset.
-	  </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN101"
-></A
-><H2
->EXAMPLE</H2
-><P
->        The DNS administrator for a DNSSEC-aware <TT
-CLASS="USERINPUT"
-><B
->.com</B
-></TT
->
-	zone would use the following command to sign the
-	<TT
-CLASS="FILENAME"
->keyset</TT
-> file for <TT
-CLASS="USERINPUT"
-><B
->example.com</B
-></TT
->
-	created by <B
-CLASS="COMMAND"
->dnssec-makekeyset</B
-> with a key generated
-	by <B
-CLASS="COMMAND"
->dnssec-keygen</B
->:
-    </P
-><P
->        <TT
-CLASS="USERINPUT"
-><B
->dnssec-signkey keyset-example.com. Kcom.+003+51944</B
-></TT
->
-    </P
-><P
->        In this example, <B
-CLASS="COMMAND"
->dnssec-signkey</B
-> creates
-	the file <TT
-CLASS="FILENAME"
->signedkey-example.com.</TT
->, which
-	contains the <TT
-CLASS="USERINPUT"
-><B
->example.com</B
-></TT
-> keys and the
-	signatures by the <TT
-CLASS="USERINPUT"
-><B
->.com</B
-></TT
-> keys.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN116"
-></A
-><H2
->SEE ALSO</H2
-><P
->      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-keygen</SPAN
->(8)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-makekeyset</SPAN
->(8)</SPAN
->,
-      <SPAN
-CLASS="CITEREFENTRY"
-><SPAN
-CLASS="REFENTRYTITLE"
->dnssec-signzone</SPAN
->(8)</SPAN
->.
-    </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN128"
-></A
-><H2
->AUTHOR</H2
-><P
->        Internet Software Consortium
-    </P
-></DIV
-></BODY
-></HTML
->
diff --git a/contrib/bind9/doc/arm/isc.color.gif b/contrib/bind9/doc/arm/isc.color.gif
deleted file mode 100644
index 09c327cca65d..000000000000
--- a/contrib/bind9/doc/arm/isc.color.gif
+++ /dev/null
diff --git a/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in b/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in
deleted file mode 100644
index 33fc938777a4..000000000000
--- a/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in
+++ /dev/null
@@ -1,148 +0,0 @@
-<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
-<!ENTITY dbstyle SYSTEM "@HTMLSTYLE@" CDATA DSSSL>
-]>
-
-<style-sheet>
-<style-specification use="docbook">
-<style-specification-body>
-
-<!-- ;; your stuff goes here... -->
-
-(define %html-prefix% 
-  ;; Add the specified prefix to HTML output filenames
-  "Bv9ARM.")
-
-(define %use-id-as-filename%
-  ;; Use ID attributes as name for component HTML files?
-  #t)
-
-(define %root-filename%
-  ;; Name for the root HTML document
-  "Bv9ARM")
-
-(define %section-autolabel%
-  ;; REFENTRY section-autolabel
-  ;; PURP Are sections enumerated?
-  ;; DESC
-  ;; If true, unlabeled sections will be enumerated.
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #t)
-
-(define %html-ext% 
-  ;; REFENTRY html-ext
-  ;; PURP Default extension for HTML output files
-  ;; DESC
-  ;; The default extension for HTML output files.
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  ".html")
-
-(define nochunks
-  ;; REFENTRY nochunks
-  ;; PURP Suppress chunking of output pages
-  ;; DESC
-  ;; If true, the entire source document is formatted as a single HTML
-  ;; document and output on stdout.
-  ;; (This option can conveniently be set with '-V nochunks' on the 
-  ;; Jade command line).
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #f)
-
-(define rootchunk
-  ;; REFENTRY rootchunk
-  ;; PURP Make a chunk for the root element when nochunks is used
-  ;; DESC
-  ;; If true, a chunk will be created for the root element, even though
-  ;; nochunks is specified. This option has no effect if nochunks is not
-  ;; true.
-  ;; (This option can conveniently be set with '-V rootchunk' on the 
-  ;; Jade command line).
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #t)
-
-(define html-index
-  ;; REFENTRY html-index
-  ;; PURP HTML indexing?
-  ;; DESC
-  ;; Turns on HTML indexing.  If true, then index data will be written
-  ;; to the file defined by 'html-index-filename'.  This data can be
-  ;; collated and turned into a DocBook index with bin/collateindex.pl.
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #t)
-
-(define html-manifest
-  ;; REFENTRY html-manifest
-  ;; PURP Write a manifest?
-  ;; DESC
-  ;; If not '#f' then the list of HTML files created by the stylesheet
-  ;; will be written to the file named by 'html-manifest-filename'.
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #t)
-
-(define (chunk-element-list)
-  (list (normalize "preface")
-	(normalize "chapter")
-	(normalize "appendix") 
-	(normalize "article")
-	(normalize "glossary")
-	(normalize "bibliography")
-	(normalize "index")
-	(normalize "colophon")
-	(normalize "setindex")
-	(normalize "reference")
-	(normalize "refentry")
-	(normalize "part")
-	(normalize "book") ;; just in case nothing else matches...
-	(normalize "set")  ;; sets are definitely chunks...
-	))
-
-;
-; Add some cell padding to tables so that they don't look so cramped
-; in Netscape.
-;
-; The following definition was cut-and-pasted from dbtable.dsl and the 
-; single line containing the word CELLPADDING was added.
-;
-(element tgroup
-  (let* ((wrapper   (parent (current-node)))
-	 (frameattr (attribute-string (normalize "frame") wrapper))
-	 (pgwide    (attribute-string (normalize "pgwide") wrapper))
-	 (footnotes (select-elements (descendants (current-node)) 
-				     (normalize "footnote")))
-	 (border (if (equal? frameattr (normalize "none"))
-		     '(("BORDER" "0"))
-		     '(("BORDER" "1"))))
-	 (width (if (equal? pgwide "1")
-		    (list (list "WIDTH" ($table-width$)))
-		    '()))
-	 (head (select-elements (children (current-node)) (normalize "thead")))
-	 (body (select-elements (children (current-node)) (normalize "tbody")))
-	 (feet (select-elements (children (current-node)) (normalize "tfoot"))))
-    (make element gi: "TABLE"
-	  attributes: (append
-		       '(("CELLPADDING" "3"))
-		       border
-		       width
-		       (if %cals-table-class%
-			   (list (list "CLASS" %cals-table-class%))
-			   '()))
-	  (process-node-list head)
-	  (process-node-list body)
-	  (process-node-list feet)
-	  (make-table-endnotes))))
-
-</style-specification-body>
-</style-specification>
-<external-specification id="docbook" document="dbstyle">
-</style-sheet>
diff --git a/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in b/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in
deleted file mode 100644
index 511d6c48bc8c..000000000000
--- a/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in
+++ /dev/null
@@ -1,42 +0,0 @@
-<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
-<!ENTITY dbstyle SYSTEM "@PRINTSTYLE@" CDATA DSSSL>
-]>
-
-
-<style-sheet>
-<style-specification use="docbook">
-<style-specification-body>
-
-<!-- ;; your stuff goes here... -->
-
-(define %generate-book-titlepage% #t)
-
-(define %section-autolabel%
-  ;; REFENTRY section-autolabel
-  ;; PURP Are sections enumerated?
-  ;; DESC
-  ;; If true, unlabeled sections will be enumerated.
-  ;; /DESC
-  ;; AUTHOR N/A
-  ;; /REFENTRY
-  #t)
-
-;; Margins around cell contents
-;; (define %cals-cell-before-row-margin% 20pt)
-;; (define %cals-cell-after-row-margin% 20pt)
-
-;; seems to be a bug in JadeTeX -- we get a wierd indent on table
-;;   cells for the first line only.  This is a workaround.
-;; Adam Di Carlo, adam@onshore.com
-(define %cals-cell-before-column-margin% 5pt)
-(define %cals-cell-after-column-margin% 5pt)
-
-;; Inheritable start and end indent for cell contents
-(define %cals-cell-content-start-indent% 5pt)
-(define %cals-cell-content-end-indent% 5pt)
-
-
-</style-specification-body>
-</style-specification>
-<external-specification id="docbook" document="dbstyle">
-</style-sheet>
diff --git a/contrib/bind9/doc/arm/validate.sh.in b/contrib/bind9/doc/arm/validate.sh.in
deleted file mode 100644
index f50d8a09dbda..000000000000
--- a/contrib/bind9/doc/arm/validate.sh.in
+++ /dev/null
@@ -1,21 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2000, 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
-#
-# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-# AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-# PERFORMANCE OF THIS SOFTWARE.
-
-# $Id: validate.sh.in,v 1.2.206.1 2004/03/06 13:16:14 marka Exp $
-
-nsgmls -sv @SGMLDIR@/docbook/dsssl/modular/dtds/decls/xml.dcl \
-       Bv9ARM-book.xml
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
deleted file mode 100644
index 09776618f2ae..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
+++ /dev/null
@@ -1,561 +0,0 @@
-
-
-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/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
deleted file mode 100644
index 0783e7b26e14..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
+++ /dev/null
@@ -1,1457 +0,0 @@
-
-
-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/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
deleted file mode 100644
index 5728b35c9ba5..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
+++ /dev/null
@@ -1,3193 +0,0 @@
-
-
-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/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
deleted file mode 100644
index 79a17284357c..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
+++ /dev/null
@@ -1,1849 +0,0 @@
-
-
-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/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt
deleted file mode 100644
index 4cfd417804d3..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt
+++ /dev/null
@@ -1,639 +0,0 @@
-
-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/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt
deleted file mode 100644
index 123d3cc09611..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt
+++ /dev/null
@@ -1,335 +0,0 @@
-
-DNS Extensions Working Group                                 J. Schlyter
-Internet-Draft                                           August 24, 2004
-Expires: February 22, 2005
-
-
-                     RFC 3597 Interoperability Report
-                   draft-ietf-dnsext-interop3597-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 3667.
-
-    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 22, 2005.
-
-Copyright Notice
-
-    Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-    This memo documents the result from the RFC 3597 (Handling of Unknown
-    DNS Resource Record Types) interoperability testing.
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter               Expires February 22, 2005                [Page 1]
-
-Internet-Draft      RFC 3597 Interoperability Report         August 2004
-
-
-Table of Contents
-
-    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-    2.  Implementations  . . . . . . . . . . . . . . . . . . . . . . .  3
-    3.  Tests  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-    3.1 Authoritative Primary Name Server  . . . . . . . . . . . . . .  3
-    3.2 Authoritative Secondary Name Server  . . . . . . . . . . . . .  3
-    3.3 Full Recursive Resolver  . . . . . . . . . . . . . . . . . . .  3
-    3.4 Stub Resolver  . . . . . . . . . . . . . . . . . . . . . . . .  3
-    3.5 DNSSEC Signer  . . . . . . . . . . . . . . . . . . . . . . . .  4
-    4.  Problems found . . . . . . . . . . . . . . . . . . . . . . . .  4
-    5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-        Normative References . . . . . . . . . . . . . . . . . . . . .  4
-        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
-    A.  Test zone data . . . . . . . . . . . . . . . . . . . . . . . .  5
-        Intellectual Property and Copyright Statements . . . . . . . .  6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter               Expires February 22, 2005                [Page 2]
-
-Internet-Draft      RFC 3597 Interoperability Report         August 2004
-
-
-1. Introduction
-
-    This memo documents the result from the RFC 3597 (Handling of Unknown
-    DNS Resource Record Types) interoperability testing.  The test was
-    performed during June and July 2004 by request of the IETF DNS
-    Extensions Working Group.
-
-2. Implementations
-
-    The following is a list, in alphabetic order, of implementations for
-    compliance of RFC 3597:
-
-       DNSJava 1.6.4
-       ISC BIND 8.4.5rc4
-       ISC BIND 9.3.0rc2
-       NSD 2.1.1
-       Net::DNS 0.47 patchlevel 1
-       Nominum ANS 2.2.1.0.d
-
-    These implementations covers the following functions (number of
-    implementations tested for each function in paranthesis):
-
-       Authoritative Name Servers (4)
-       Full Recursive Resolver (2)
-       Stub Resolver (4)
-       DNSSEC Zone Signers (2)
-
-3. Tests
-
-3.1 Authoritative Primary Name Server
-
-    The test zone data (Appendix A) was loaded into the name server
-    implementation and the server was queried for the loaded information.
-
-3.2 Authoritative Secondary Name Server
-
-    The test zone data (Appendix A) was transferred using AXFR from
-    another name server implementation and the server was queried for the
-    transferred information.
-
-3.3 Full Recursive Resolver
-
-    A recursive resolver was queried for resource records from a domain
-    with the test zone data (Appendix A).
-
-3.4 Stub Resolver
-
-    A stub resolver was used to query resource records from a domain with
-
-
-
-Schlyter               Expires February 22, 2005                [Page 3]
-
-Internet-Draft      RFC 3597 Interoperability Report         August 2004
-
-
-    the test zone data (Appendix A).
-
-3.5 DNSSEC Signer
-
-    A DNSSEC signer was used to sign a zone with test zone data (Appendix
-    A).
-
-4. Problems found
-
-    Two implementations had problems with text presentation of zero
-    length RDATA.
-
-    One implementation had problems with text presentation of RR type
-    code and classes >= 4096.
-
-    Bug reports were filed for problems found.
-
-5. Summary
-
-    Unknown type codes works in the tested authoritative servers,
-    recursive resolvers and stub clients.
-
-    No changes are needed to advance RFC 3597 to draft standard.
-
-Normative References
-
-    [1]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-
-Author's Address
-
-    Jakob Schlyter
-
-    EMail: jakob@rfc.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter               Expires February 22, 2005                [Page 4]
-
-Internet-Draft      RFC 3597 Interoperability Report         August 2004
-
-
-Appendix A. Test zone data
-
-    ; A-record encoded as TYPE1
-    a  TYPE1  \# 4 7f000001
-    a  TYPE1  192.0.2.1
-    a  A      \# 4 7f000002
-
-    ; draft-ietf-secsh-dns-05.txt
-    sshfp  TYPE44  \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
-
-    ; bogus test record (from RFC 3597)
-    type731    TYPE731    \# 6 abcd (
-                               ef 01 23 45 )
-
-    ; zero length RDATA (from RFC 3597)
-    type62347  TYPE62347  \# 0
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter               Expires February 22, 2005                [Page 5]
-
-Internet-Draft      RFC 3597 Interoperability Report         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 IETF's procedures with respect to rights in IETF Documents can
-    be found in BCP 78 and BCP 79.
-
-    Copies of IPR disclosures made to the IETF Secretariat and any
-    assurances of licenses to be made available, or the result of an
-    attempt made to obtain a general license or permission for the use of
-    such proprietary rights by implementers or users of this
-    specification can be obtained from the IETF on-line IPR repository at
-    http://www.ietf.org/ipr.
-
-    The IETF invites any interested party to bring to its attention any
-    copyrights, patents or patent applications, or other proprietary
-    rights that may cover technology that may be required to implement
-    this standard. Please address the information to the IETF at
-    ietf-ipr@ietf.org.
-
-
-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.
-
-
-
-
-Schlyter               Expires February 22, 2005                [Page 6]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt
deleted file mode 100644
index 8dcacc8bb9ec..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt
+++ /dev/null
@@ -1,1559 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group                                        Levon Esibov
-INTERNET-DRAFT                                             Bernard Aboba
-Category: Standards Track                                    Dave Thaler
-<draft-ietf-dnsext-mdns-33.txt>                                Microsoft
-18 July 2004
-
-
-              Linklocal Multicast Name Resolution (LLMNR)
-
-   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 2, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2004.  All rights reserved.
-
-Abstract
-
-   Today, with the rise of home networking, there are an increasing
-   number of ad-hoc networks operating without a Domain Name System
-   (DNS) server.  The goal of Link-Local Multicast Name Resolution
-   (LLMNR) is to enable name resolution in scenarios in which
-   conventional DNS name resolution is not possible.  LLMNR supports all
-   current and future DNS formats, types and classes, while operating on
-   a separate port from DNS, and with a distinct resolver cache.  Since
-   LLMNR only operates on the local link, it cannot be considered a
-   substitute for DNS.
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 1]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-Table of Contents
-
-1.     Introduction ..........................................    3
-   1.1       Requirements ....................................    4
-   1.2       Terminology .....................................    4
-2.     Name resolution using LLMNR ...........................    4
-   2.1       LLMNR packet format .............................    6
-   2.2       Sender behavior .................................    8
-   2.3       Responder behavior ..............................    8
-   2.4       Unicast queries .................................   11
-   2.5       Off-link detection ..............................   11
-   2.6       Responder responsibilities ......................   12
-   2.7       Retransmission and jitter .......................   13
-   2.8       DNS TTL .........................................   13
-   2.9       Use of the authority and additional sections ....   14
-3.     Usage model ...........................................   14
-   3.1       LLMNR configuration .............................   15
-4.     Conflict resolution ...................................   16
-   4.1       Considerations for multiple interfaces ..........   18
-   4.2       API issues ......................................   19
-5.     Security considerations ...............................   20
-   5.1       Scope restriction ...............................   20
-   5.2       Usage restriction ...............................   21
-   5.3       Cache and port separation .......................   22
-   5.4       Authentication ..................................   22
-6.     IANA considerations ...................................   22
-7.     References ............................................   22
-   7.1       Normative References ............................   22
-   7.2       Informative References ..........................   23
-Acknowledgments ..............................................   24
-Authors' Addresses ...........................................   25
-Intellectual Property Statement ..............................   25
-Disclaimer of Validity .......................................   26
-Full Copyright Statement .....................................   26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 2]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-1.  Introduction
-
-   This document discusses Link Local Multicast Name Resolution (LLMNR),
-   which utilizes the DNS packet format and supports all current and
-   future DNS formats, types and classes.  LLMNR operates on a separate
-   port from the Domain Name System (DNS), with a distinct resolver
-   cache.
-
-   The goal of LLMNR is to enable name resolution in scenarios in which
-   conventional DNS name resolution is not possible.  These include
-   scenarios in which hosts are not configured with the address of a DNS
-   server, where configured DNS servers do not reply to a query, or
-   where they respond with errors, as described in Section 2.  Since
-   LLMNR only operates on the local link, it cannot be considered a
-   substitute for DNS.
-
-   Link-scope multicast addresses are used to prevent propagation of
-   LLMNR traffic across routers, potentially flooding the network.
-   LLMNR queries can also be sent to a unicast address, as described in
-   Section 2.4.
-
-   Propagation of LLMNR packets on the local link is considered
-   sufficient to enable name resolution in small networks.  The
-   assumption is that if a network has a gateway, then the network is
-   able to provide DNS server configuration.   Configuration issues are
-   discussed in Section 3.1.
-
-   In the future, it may be desirable to consider use of multicast name
-   resolution with multicast scopes beyond the link-scope.  This could
-   occur if LLMNR deployment is successful, the need arises for
-   multicast name resolution beyond the link-scope, or multicast routing
-   becomes ubiquitous.  For example, expanded support for multicast name
-   resolution might be required for mobile ad-hoc networking scenarios,
-   or where no DNS server is available that is authoritative for the
-   names of local hosts, and can support dynamic DNS, such as in
-   wireless hotspots.
-
-   Once we have experience in LLMNR deployment in terms of
-   administrative issues, usability and impact on the network, it will
-   be possible to reevaluate which multicast scopes are appropriate for
-   use with multicast name resolution.
-
-   Service discovery in general, as well as discovery of DNS servers
-   using LLMNR in particular, is outside of the scope of this document,
-   as is name resolution over non-multicast capable media.
-
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 3]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-1.1.  Requirements
-
-   In this document, several words are used to signify the requirements
-   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
-   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
-   and "OPTIONAL" in this document are to be interpreted as described in
-   [RFC2119].
-
-1.2.  Terminology
-
-   This document assumes familiarity with DNS terminology defined in
-   [RFC1035].  Other terminology used in this document includes:
-
-Positively Resolved
-     Responses with RCODE set to zero are referred to in this document
-     as "positively resolved".
-
-Routable Address
-     An address other than a Link-Local address.  This includes globally
-     routable addresses, as well as private addresses.
-
-Reachable
-     An address is considered reachable over a link if either an ARP or
-     neighbor discovery cache entry exists for the address on the link.
-
-Responder
-     A host that listens to LLMNR queries, and responds to those for
-     which it is authoritative.
-
-Sender
-     A host that sends an LLMNR query.
-
-2.  Name resolution using LLMNR
-
-   LLMNR is a peer-to-peer name resolution protocol that is not intended
-   as a replacement for DNS.  LLMNR queries are sent to and received on
-   port 5355.  IPv4 administratively scoped multicast usage is specified
-   in "Administratively Scoped IP Multicast" [RFC2365].  The IPv4 link-
-   scope multicast address a given responder listens to, and to which a
-   sender sends queries, is 224.0.0.252.  The IPv6 link-scope multicast
-   address a given responder listens to, and to which a sender sends all
-   queries, is FF02:0:0:0:0:0:1:3.
-
-   Typically a host is configured as both an LLMNR sender and a
-   responder.  A host MAY be configured as a sender, but not a
-   responder.  However, a host configured as a responder MUST act as a
-   sender to verify the uniqueness of names as described in Section 4.
-   This document does not specify how names are chosen or configured.
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 4]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   This may occur via any mechanism, including DHCPv4 [RFC2131] or
-   DHCPv6 [RFC3315].
-
-   LLMNR usage MAY be configured manually or automatically on a per
-   interface basis.  By default, LLMNR responders SHOULD be enabled on
-   all interfaces, at all times.  Enabling LLMNR for use in situations
-   where a DNS server has been configured will result in a change in
-   default behavior without a simultaneous update to configuration
-   information. Where this is considered undesirable, LLMNR SHOULD NOT
-   be enabled by default, so that hosts will neither listen on the link-
-   scope multicast address, nor will they send queries to that address.
-
-   An LLMNR sender may send a request for any name.  However, by
-   default, LLMNR requests SHOULD be sent only when one of the following
-   conditions are met:
-
-   [1] No manual or automatic DNS configuration has been
-       performed.  If an interface has been configured with DNS
-       server address(es),  then LLMNR SHOULD NOT be used as the
-       primary name resolution mechanism on that interface, although
-       it MAY be used as a name resolution mechanism of last resort.
-
-   [2] DNS servers do not respond.
-
-   [3] DNS servers respond to a DNS query with RCODE=3
-       (Authoritative Name Error) or RCODE=0, and an empty
-       answer section.
-
-   A typical sequence of events for LLMNR usage is as follows:
-
-   [a]  DNS servers are not configured or do not respond to a
-        DNS query, or respond with RCODE=3, or RCODE=0 and an
-        empty answer section.
-
-   [b]  An LLMNR sender sends an LLMNR query to the link-scope
-        multicast address(es) defined in Section 2, unless a
-        unicast query is indicated.  A sender SHOULD send LLMNR
-        queries for PTR RRs via unicast, as specified in Section 2.4.
-
-   [c]  A responder responds to this query only if it is authoritative
-        for the domain name in the query.  A responder responds to a
-        multicast query by sending a unicast UDP response to the sender.
-        Unicast queries are responded to as indicated in Section 2.4.
-
-   [d]  Upon reception of the response, the sender processes it.
-
-   Further details of sender and responder behavior are provided in the
-   sections that follow.
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 5]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-2.1.  LLMNR packet format
-
-   LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4
-   for both queries and responses.  LLMNR implementations SHOULD send
-   UDP queries and responses only as large as are known to be
-   permissible without causing fragmentation.  When in doubt a maximum
-   packet size of 512 octets SHOULD be used.  LLMNR implementations MUST
-   accept UDP queries and responses as large as permitted by the link
-   MTU.
-
-2.1.1.  LLMNR header format
-
-   LLMNR queries and responses utilize the DNS header format defined in
-   [RFC1035] with exceptions noted below:
-
-                                   1  1  1  1  1  1
-     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                      ID                       |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |QR|   Opcode  | Z|TC| Z| Z| Z| Z| Z|   RCODE   |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    QDCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    ANCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    NSCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   |                    ARCOUNT                    |
-   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-ID   A 16 bit identifier assigned by the program that generates any kind
-     of query.  This identifier is copied from the query to the response
-     and can be used by the sender to match responses to outstanding
-     queries. The ID field in a query SHOULD be set to a pseudo-random
-     value.
-
-QR   A one bit field that specifies whether this message is an LLMNR
-     query (0), or an LLMNR response (1).
-
-OPCODE
-     A four bit field that specifies the kind of query in this message.
-     This value is set by the originator of a query and copied into the
-     response.  This specification defines the behavior of standard
-     queries and responses (opcode value of zero).  Future
-     specifications may define the use of other opcodes with LLMNR.
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 6]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-     LLMNR senders and responders MUST support standard queries (opcode
-     value of zero).  LLMNR queries with unsupported OPCODE values MUST
-     be silently discarded by responders.
-
-TC   TrunCation - specifies that this message was truncated due to
-     length greater than that permitted on the transmission channel.
-     The TC bit MUST NOT be set in an LLMNR query and if set is ignored
-     by an LLMNR responder.  If the TC bit is set an LLMNR response,
-     then the sender MAY use the response if it contains all necessary
-     information, or the sender MAY discard the response and resend the
-     LLMNR query over TCP using the unicast address of the responder as
-     the destination address.  See  [RFC2181] and Section 2.4 of this
-     specification for further discussion of the TC bit.
-
-Z    Reserved for future use.  Implementations of this specification
-     MUST set these bits to zero in both queries and responses.  If
-     these bits are set in a LLMNR query or response, implementations of
-     this specification MUST ignore them.  Since reserved bits could
-     conceivably be used for different purposes than in DNS,
-     implementors are advised not to enable processing of these bits in
-     an LLMNR implementation starting from a DNS code base.
-
-RCODE
-     Response code -- this 4 bit field is set as part of LLMNR
-     responses.  In an LLMNR query, the RCODE MUST be zero, and is
-     ignored by the responder.  The response to a multicast LLMNR query
-     MUST have RCODE set to zero.  A sender MUST silently discard an
-     LLMNR response with a non-zero RCODE sent in response to a
-     multicast query.
-
-     If an LLMNR responder is authoritative for the name in a multicast
-     query, but an error is encountered, the responder SHOULD send an
-     LLMNR response with an RCODE of zero, no RRs in the answer section,
-     and the TC bit set.  This will cause the query to be resent using
-     TCP, and allow the inclusion of a non-zero RCODE in the response to
-     the TCP query.  Responding with the TC bit set is preferrable to
-     not sending a response, since it enables errors to be diagnosed.
-
-     Since LLMNR responders only respond to LLMNR queries for names for
-     which they are authoritative, LLMNR responders MUST NOT respond
-     with an RCODE of 3; instead, they should not respond at all.
-
-     LLMNR implementations MUST support EDNS0 [RFC2671] and extended
-     RCODE values.
-
-QDCOUNT
-     An unsigned 16 bit integer specifying the number of entries in the
-     question section. A sender MUST place only one question into the
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 7]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-     question section of an LLMNR query.  LLMNR responders MUST silently
-     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders
-     MUST silently discard LLMNR responses with QDCOUNT not equal to
-     one.
-
-ANCOUNT
-     An unsigned 16 bit integer specifying the number of resource
-     records in the answer section.  LLMNR responders MUST silently
-     discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
-     An unsigned 16 bit integer specifying the number of name server
-     resource records in the authority records section.  Authority
-     record section processing is described in Section 2.9.
-
-ARCOUNT
-     An unsigned 16 bit integer specifying the number of resource
-     records in the additional records section.  Additional record
-     section processing is described in Section 2.9.
-
-2.2.  Sender behavior
-
-   A sender may send an LLMNR query for any legal resource record  type
-   (e.g.  A, AAAA, SRV, etc.) to the link-scope multicast address.
-
-   As described in Section 2.4, a sender may also send a unicast query.
-   Sections 2 and 3 describe the circumstances in which LLMNR queries
-   may be sent.
-
-   The sender MUST anticipate receiving no replies to some LLMNR
-   queries, in the event that no responders are available within the
-   link-scope or in the event no positive non-null responses exist for
-   the transmitted query.  If no positive response is received, a
-   resolver treats it as a response that no records of the specified
-   type and class exist for the specified name (it is treated the same
-   as a response with RCODE=0 and an empty answer section).
-
-   Since the responder may order the RRs in the response so as to
-   indicate preference, the sender SHOULD preserve ordering in the
-   response to the querying application.
-
-2.3.  Responder behavior
-
-   An LLMNR response MUST be sent to the sender via unicast.
-
-   Upon configuring an IP address responders typically will synthesize
-   corresponding A, AAAA and PTR RRs so as to be able to respond to
-   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 8]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   responder has another RR as well;  the SOA RR MUST NOT be the only RR
-   that a responder has.  However, in general whether RRs are manually
-   or automatically created is an implementation decision.
-
-   For example, a host configured to have computer name "host1" and to
-   be a member of the "example.com" domain, and with IPv4 address
-   10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
-   authoritative for the following records:
-
-   host1. IN A 10.1.1.1
-   IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   host1.example.com. IN A 10.1.1.1
-   IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   1.1.1.10.in-addr.arpa. IN PTR host1.
-   IN PTR host1.example.com.
-
-   6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
-   IN PTR host1.
-   IN PTR host1.example.com
-
-   An LLMNR responder might be further manually configured with the name
-   of a local mail server with an MX RR included in the "host1." and
-   "host1.example.com." records.
-
-   In responding to queries:
-
-[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
-     address(es) defined in Section 2, and on UDP and TCP port 5355 on
-     the unicast address(es) that could be set as the source address(es)
-     when the responder responds to the LLMNR query.
-
-[b]  Responders MUST direct responses to the port from which the query
-     was sent.  When queries are received via TCP this is an inherent
-     part of the transport protocol.  For queries received by UDP the
-     responder MUST take note of the source port and use that as the
-     destination port in the response.  Responses SHOULD always be sent
-     from the port to which they were directed.
-
-[c]  Responders MUST respond to LLMNR queries for names and addresses
-     they are authoritative for.  This applies to both forward and
-     reverse lookups.
-
-[d]  Responders MUST NOT respond to LLMNR queries for names they are not
-     authoritative for.
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                    [Page 9]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-[e]  Responders MUST NOT respond using cached data.
-
-[f]  If a DNS server is running on a host that supports LLMNR, the DNS
-     server MUST respond to LLMNR queries only for the RRSets relating
-     to the host on which the server is running, but MUST NOT respond
-     for other records for which the server is authoritative.  DNS
-     servers also MUST NOT send LLMNR queries in order to resolve DNS
-     queries.
-
-[g]  If a responder is authoritative for a name, it MAY respond with
-     RCODE=0 and an empty answer section, if the type of query does not
-     match a RR that the responder has.
-
-   As an example, a host configured to respond to LLMNR queries for the
-   name "foo.example.com."  is authoritative for the name
-   "foo.example.com.".  On receiving an LLMNR query for an A RR with the
-   name "foo.example.com." the host authoritatively responds with A
-   RR(s) that contain IP address(es) in the RDATA of the resource
-   record.  If the responder has a AAAA RR, but no A RR, and an A RR
-   query is received, the responder would respond with RCODE=0 and an
-   empty answer section.
-
-   In conventional DNS terminology a DNS server authoritative for a zone
-   is authoritative for all the domain names under the zone apex except
-   for the branches delegated into separate zones.  Contrary to
-   conventional DNS terminology, an LLMNR responder is authoritative
-   only for the zone apex.
-
-   For example the host "foo.example.com." is not authoritative for the
-   name "child.foo.example.com." unless the host is configured with
-   multiple names, including "foo.example.com."  and
-   "child.foo.example.com.".  As a result, "foo.example.com." cannot
-   reply to an LLMNR query for "child.foo.example.com." with RCODE=3
-   (authoritative name error).  The purpose of limiting the name
-   authority scope of a responder is to prevent complications that could
-   be caused by coexistence of two or more hosts with the names
-   representing child and parent (or grandparent) nodes in the DNS tree,
-   for example, "foo.example.com." and "child.foo.example.com.".
-
-   In this example (unless this limitation is introduced) an LLMNR query
-   for an A resource record for the name "child.foo.example.com." would
-   result in two authoritative responses: RCODE=3 (authoritative name
-   error) received from "foo.example.com.", and a requested A record -
-   from "child.foo.example.com.".  To prevent this ambiguity, LLMNR
-   enabled hosts could perform a dynamic update of the parent (or
-   grandparent) zone with a delegation to a child zone.  In this example
-   a host "child.foo.example.com." would send a dynamic update for the
-   NS and glue A record to "foo.example.com.", but this approach
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 10]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   significantly complicates implementation of LLMNR and would not be
-   acceptable for lightweight hosts.
-
-2.4.  Unicast queries and responses
-
-   Unicast queries SHOULD be sent when:
-
-   [a] A sender repeats a query after it received a response
-       with the TC bit set to the previous LLMNR multicast query, or
-
-   [b] The sender queries for a PTR RR of a fully formed IP address
-       within the "in-addr.arpa" or "ip6.arpa" zones.
-
-   Unicast LLMNR queries MUST be done using TCP and the responses MUST
-   be sent using the same TCP connection as the query.  Senders MUST
-   support sending TCP queries, and responders MUST support listening
-   for TCP queries. If the sender of a TCP query receives a response to
-   that query not using TCP, the response MUST be silently discarded.
-
-   Unicast UDP queries MUST be silently discarded.
-
-   If TCP connection setup cannot be completed in order to send a
-   unicast TCP query, this is treated as a response that no records of
-   the specified type and class exist for the specified name (it is
-   treated the same as a response with RCODE=0 and an empty answer
-   section).
-
-2.5.  "Off link" detection
-
-   For IPv4, an "on link" address is defined as a link-local address
-   [IPv4Link] or an address whose prefix belongs to a subnet on the
-   local link.  For IPv6 [RFC2460] an "on link" address is either a
-   link-local address, defined in [RFC2373], or an address whose prefix
-   belongs to a subnet on the local link.
-
-   A sender MUST select a source address for LLMNR queries that is "on
-   link".  The destination address of an LLMNR query MUST be a link-
-   scope multicast address or an "on link" unicast address.
-
-   A responder MUST select a source address for responses that is "on
-   link". The destination address of an LLMNR response MUST be an "on
-   link" unicast address.
-
-   On receiving an LLMNR query, the responder MUST check whether it was
-   sent to a LLMNR multicast addresses defined in Section 2.  If it was
-   sent to another multicast address, then the query MUST be silently
-   discarded.
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 11]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
-   composing an LLMNR query using TCP, the sender MUST set the Hop Limit
-   field in the IPv6 header and the TTL field in the IPv4 header of the
-   response to one (1).  The responder SHOULD set the TTL or Hop Limit
-   settings on the TCP listen socket to one (1) so that SYN-ACK packets
-   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
-   prevents an incoming connection from off-link since the sender will
-   not receive a SYN-ACK from the responder.
-
-   For UDP queries and responses the Hop Limit field in the IPv6 header,
-   and the TTL field in the IPV4 header MAY be set to any value.
-   However, it is RECOMMENDED that the value 255 be used for
-   compatibility with Apple Rendezvous.
-
-   Implementation note:
-
-      In the sockets API for IPv4 [POSIX], the IP_TTL and
-      IP_MULTICAST_TTL socket options are used to set the TTL of
-      outgoing unicast and multicast packets. The IP_RECVTTL socket
-      option is available on some platforms to retrieve the IPv4 TTL of
-      received packets with recvmsg().  [RFC2292] specifies similar
-      options for setting and retrieving the IPv6 Hop Limit.
-
-2.6.  Responder responsibilities
-
-   It is the responsibility of the responder to ensure that RRs returned
-   in LLMNR responses MUST only include values that are valid on the
-   local interface, such as IPv4 or IPv6 addresses valid on the local
-   link or names defended using the mechanism described in Section 4.
-   In particular:
-
-   [a] If a link-scope IPv6 address is returned in a AAAA RR,
-       that address MUST be valid on the local link over which
-       LLMNR is used.
-
-   [b] If an IPv4 address is returned, it MUST be reachable
-       through the link over which LLMNR is used.
-
-   [c] If a name is returned (for example in a CNAME, MX
-       or SRV RR), the name MUST be resolvable on the local
-       link over which LLMNR is used.
-
-   Routable addresses MUST be included first in the response, if
-   available.  This encourages use of routable address(es) for
-   establishment of new connections.
-
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 12]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-2.7.  Retransmission and jitter
-
-   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
-   when to retransmit an LLMNR query and how long to collect responses
-   to an LLMNR query.
-
-   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
-   then a sender MAY repeat the transmission of the query in order to
-   assure that it was received by a host capable of responding to it.
-   Retransmission of UDP queries SHOULD NOT be attempted more than 3
-   times. Where LLMNR queries are sent using TCP, retransmission is
-   handled by the transport layer.
-
-   Because an LLMNR sender cannot know in advance if a query sent using
-   multicast will receive no response, one response, or more than one
-   response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
-   collect all possible responses, rather than considering the multicast
-   query answered after the first response is received. A unicast query
-   sender considers the query answered after the first response is
-   received, so that it only waits for LLMNR_TIMEOUT if no response has
-   been received.
-
-   An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
-   for each transmission. It is suggested that the computation of
-   LLMNR_TIMEOUT be based on the response times for earlier LLMNR
-   queries sent on the same interface.
-
-   For example, the algorithms described in RFC 2988 [RFC2988]
-   (including exponential backoff) compute an RTO, which is used as the
-   value of LLMNR_TIMEOUT.  Smaller values MAY be used for the initial
-   RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum
-   RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the
-   maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
-
-   Recommended values are an initial RTO of 1 second, a minimum RTO of
-   200ms, and a maximum RTO of 5 seconds.  In order to avoid
-   synchronization, the transmission of each LLMNR query and response
-   SHOULD delayed by a time randomly selected from the interval 0 to 100
-   ms.  This delay MAY be avoided by responders responding with RRs
-   which they have previously determined to be UNIQUE (see Section 4 for
-   details).
-
-2.8.  DNS TTL
-
-   The responder should use a pre-configured TTL value in the records
-   returned an LLMNR response.  A default value of 30 seconds is
-   RECOMMENDED.  In highly dynamic environments (such as mobile ad-hoc
-   networks), the TTL value may need to be reduced.
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 13]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   Due to the TTL minimalization necessary when caching an RRset, all
-   TTLs in an RRset MUST be set to the same value.
-
-2.9.  Use of the authority and additional sections
-
-   Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
-   concept of delegation.  In LLMNR, the NS resource record type may be
-   stored and queried for like any other type, but it has no special
-   delegation semantics as it does in the DNS.  Responders MAY have NS
-   records associated with the names for which they are authoritative,
-   but they SHOULD NOT include these NS records in the authority
-   sections of responses.
-
-   Responders SHOULD insert an SOA record into the authority section of
-   a negative response, to facilitate negative caching as specified in
-   [RFC2308].  The owner name of this SOA record MUST be equal to the
-   query name.
-
-   Responders SHOULD NOT perform DNS additional section processing,
-   except as required for EDNS0 and DNSSEC.
-
-   Senders MUST NOT cache RRs from the authority or additional section
-   of a response as answers, though they may be used for other purposes
-   such as negative caching.
-
-3.  Usage model
-
-   Since LLMNR is a secondary name resolution mechanism, its usage is in
-   part determined by the behavior of DNS implementations.  This
-   document does not specify any changes to DNS resolver behavior, such
-   as searchlist processing or retransmission/failover policy.  However,
-   robust DNS resolver implementations are more likely to avoid
-   unnecessary LLMNR queries.
-
-   As noted in [DNSPerf], even when DNS servers are configured, a
-   significant fraction of DNS queries do not receive a response, or
-   result in negative responses due to missing inverse mappings or NS
-   records that point to nonexistent or inappropriate hosts.  This has
-   the potential to result in a large number of unnecessary LLMNR
-   queries.
-
-   [RFC1536] describes common DNS implementation errors and fixes.  If
-   the proposed fixes are implemented, unnecessary LLMNR queries will be
-   reduced substantially, and so implementation of [RFC1536] is
-   recommended.
-
-   For example, [RFC1536] Section 1 describes issues with retransmission
-   and recommends implementation of a retransmission policy based on
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 14]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   round trip estimates, with exponential backoff.  [RFC1536] Section 4
-   describes issues with failover, and recommends that resolvers try
-   another server when they don't receive a response to a query.  These
-   policies are likely to avoid unnecessary LLMNR queries.
-
-   [RFC1536] Section 3 describes zero answer bugs, which if addressed
-   will also reduce unnecessary LLMNR queries.
-
-   [RFC1536] Section 6 describes name error bugs and recommended
-   searchlist processing that will reduce unnecessary RCODE=3
-   (authoritative name) errors, thereby also reducing unnecessary LLMNR
-   queries.
-
-3.1.  LLMNR configuration
-
-   Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
-   possible for a dual stack host to be configured with the address of a
-   DNS server over IPv4, while remaining unconfigured with a DNS server
-   suitable for use over IPv6.
-
-   In these situations, a dual stack host will send AAAA queries to the
-   configured DNS server over IPv4.  However, an IPv6-only host
-   unconfigured with a DNS server suitable for use over IPv6 will be
-   unable to resolve names using DNS.  Automatic IPv6 DNS configuration
-   mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
-   deployed, and not all DNS servers support IPv6. Therefore lack of
-   IPv6 DNS configuration may be a common problem in the short term, and
-   LLMNR may prove useful in enabling linklocal name resolution over
-   IPv6.
-
-   Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
-   IPv6-only hosts may not be configured with a DNS server.  Where there
-   is no DNS server authoritative for the name of a host or the
-   authoritative DNS server does not support dynamic client update over
-   IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
-   be able to do DNS dynamic update, and other hosts will not be able to
-   resolve its name.
-
-   For example, if the configured DNS server responds to AAAA RR queries
-   sent over IPv4 or IPv6 with an authoritative name error (RCODE=3),
-   then it will not be possible to resolve the names of IPv6-only hosts.
-   In this situation, LLMNR over IPv6 can be used for local name
-   resolution.
-
-   Similarly, if a DHCPv4 server is available providing DNS server
-   configuration, and DNS server(s) exist which are authoritative for
-   the A RRs of local hosts and support either dynamic client update
-   over IPv4 or DHCPv4-based dynamic update, then the names of local
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 15]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   IPv4 hosts can be resolved over IPv4 without LLMNR.  However,  if no
-   DNS server is authoritative for the names of local hosts, or the
-   authoritative DNS server(s) do not support dynamic update, then LLMNR
-   enables linklocal name resolution over IPv4.
-
-   Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-   configure LLMNR on an interface.  The LLMNR Enable Option, described
-   in [LLMNREnable], can be used to explicitly enable or disable use of
-   LLMNR on an interface.  The LLMNR Enable Option does not determine
-   whether or in which order DNS itself is used for name resolution.
-   The order in which various name resolution mechanisms should be used
-   can be specified using the Name Service Search Option (NSSO) for DHCP
-   [RFC2937], using the LLMNR Enable Option code carried in the NSSO
-   data.
-
-   It is possible that DNS configuration mechanisms will go in and out
-   of service.  In these circumstances, it is possible for hosts within
-   an administrative domain to be inconsistent in their DNS
-   configuration.
-
-   For example, where DHCP is used for configuring DNS servers, one or
-   more DHCP servers can fail.  As a result, hosts configured prior to
-   the outage will be configured with a DNS server, while hosts
-   configured after the outage will not.  Alternatively, it is possible
-   for the DNS configuration mechanism to continue functioning while
-   configured DNS servers fail.
-
-   Unless unconfigured hosts periodically retry configuration, an outage
-   in the DNS configuration mechanism will result in hosts continuing to
-   use LLMNR even once the outage is repaired.  Since LLMNR only enables
-   linklocal name resolution, this represents an unnecessary degradation
-   in capabilities.  As a result, it is recommended that hosts without a
-   configured DNS server periodically attempt to obtain DNS
-   configuration.  For example, where DHCP is used for DNS
-   configuration, [RFC2131] recommends a maximum retry interval of 64
-   seconds.  In the absence of other guidance, a default retry interval
-   of one (1) minute is RECOMMENDED.
-
-4.  Conflict resolution
-
-   The sender MUST anticipate receiving multiple replies to the same
-   LLMNR query, in the event that several LLMNR enabled computers
-   receive the query and respond with valid answers.  When this occurs,
-   the responses may first be concatenated, and then treated in the same
-   manner that multiple RRs received from the same DNS server would; the
-   sender perceives no inherent conflict in the receipt of multiple
-   responses.
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 16]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   There are some scenarios when multiple responders MAY respond to the
-   same query.  There are other scenarios when only one responder MAY
-   respond to a query.  Resource records for which the latter queries
-   are submitted are referred as UNIQUE throughout this document.  The
-   uniqueness of a resource record depends on a nature of the name in
-   the query and type of the query.  For example it is expected that:
-
-      - multiple hosts may respond to a query for an SRV type record
-      - multiple hosts may respond to a query for an A or AAAA type
-        record for a cluster name (assigned to multiple hosts in
-        the cluster)
-      - only a single host may respond to a query for an A or AAAA
-        type record for a name.
-
-   Every responder that responds to an LLMNR query AND includes a UNIQUE
-   record in the response:
-
-   [1]  MUST verify that there is no other host within the
-        scope of the LLMNR query propagation that can return
-        a resource record for the same name, type and class.
-
-   [2]  MUST NOT include a UNIQUE resource record in the
-        response without having verified its uniqueness.
-
-   Where a host is configured to issue LLMNR queries on more than one
-   interface, each interface should have its own independent LLMNR
-   cache.  For each UNIQUE resource record in a given interface's
-   configuration, the host MUST verify resource record uniqueness on
-   that interface.  To accomplish this, the host MUST send an LLMNR
-   query for each UNIQUE resource record.
-
-   By default, a host SHOULD be configured to behave as though all RRs
-   are UNIQUE.  Uniqueness verification is carried out when the host:
-
-     - starts up or is rebooted
-     - wakes from sleep (if the network interface was inactive during sleep)
-     - is configured to respond to the LLMNR queries on an interface
-       enabled for transmission and reception of IP traffic
-     - is configured to respond to the LLMNR queries using additional
-       UNIQUE resource records
-     - detects that an interface is connected and is usable
-       (e.g. an IEEE 802 hardware link-state change indicating
-       that a cable was attached or completion of authentication
-       (and if needed, association) with a wireless base station
-       or adhoc network
-
-   When a host that has a UNIQUE record receives an LLMNR query for that
-   record, the host MUST respond.  After the client receives a response,
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 17]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   it MUST check whether the response arrived on an interface different
-   from the one on which the query was sent.  If the response arrives on
-   a different interface, the client can use the UNIQUE resource record
-   in response to LLMNR queries.  If not, then it MUST NOT use the
-   UNIQUE resource record in response to LLMNR queries.
-
-   The name conflict detection mechanism doesn't prevent name conflicts
-   when previously partitioned segments are connected by a bridge. In
-   order to minimize the chance of conflicts in such a situation, it is
-   recommended that steps be taken to ensure name uniqueness. For
-   example, the name could be chosen randomly from a large pool of
-   potential names, or the name could be assigned via a process designed
-   to guarantee uniqueness.
-
-   When name conflicts are detected, they SHOULD be logged.  To detect
-   duplicate use of a name, an administrator can use a name resolution
-   utility which employs LLMNR and lists both responses and responders.
-   This would allow an administrator to diagnose behavior and
-   potentially to intervene and reconfigure LLMNR responders who should
-   not be configured to respond to the same name.
-
-4.1.  Considerations for Multiple Interfaces
-
-   A multi-homed host may elect to configure LLMNR on only one of its
-   active interfaces.  In many situations this will be adequate.
-   However, should a host need to configure LLMNR on more than one of
-   its active interfaces, there are some additional precautions it MUST
-   take.  Implementers who are not planning to support LLMNR on multiple
-   interfaces simultaneously may skip this section.
-
-   A multi-homed host checks the uniqueness of UNIQUE records as
-   described in Section 4.  The situation is illustrated in figure 1.
-
-        ----------  ----------
-         |      |    |      |
-        [A]    [myhost]   [myhost]
-
-      Figure 1.  Link-scope name conflict
-
-   In this situation, the multi-homed myhost will probe for, and defend,
-   its host name on both interfaces.  A conflict will be detected on one
-   interface, but not the other.  The multi-homed myhost will not be
-   able to respond with a host RR for "myhost" on the interface on the
-   right (see Figure 1).  The multi-homed host may, however, be
-   configured to use the "myhost" name on the interface on the left.
-
-   Since names are only unique per-link, hosts on different links could
-   be using the same name.  If an LLMNR client sends requests over
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 18]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   multiple interfaces, and receives replies from more than one, the
-   result returned to the client is defined by the implementation.  The
-   situation is illustrated in figure 2.
-
-        ----------  ----------
-         |      |    |     |
-        [A]    [myhost]   [A]
-
-
-      Figure 2.  Off-segment name conflict
-
-   If host myhost is configured to use LLMNR on both interfaces, it will
-   send LLMNR queries on both interfaces.  When host myhost sends a
-   query for the host RR for name "A" it will receive a response from
-   hosts on both interfaces.
-
-   Host myhost cannot distinguish between the situation shown in Figure
-   2, and that shown in Figure 3 where no conflict exists.
-
-                [A]
-               |   |
-           -----   -----
-               |   |
-              [myhost]
-
-      Figure 3.  Multiple paths to same host
-
-   This illustrates that the proposed name conflict resolution mechanism
-   does not support detection or resolution of conflicts between hosts
-   on different links.  This problem can also occur with unicast DNS
-   when a multi-homed host is connected to two different networks with
-   separated name spaces.  It is not the intent of this document to
-   address the issue of uniqueness of names within DNS.
-
-4.2.  API issues
-
-   [RFC2553] provides an API which can partially solve the name
-   ambiguity problem for applications written to use this API, since the
-   sockaddr_in6 structure exposes the scope within which each scoped
-   address exists, and this structure can be used for both IPv4 (using
-   v4-mapped IPv6 addresses) and IPv6 addresses.
-
-   Following the example in Figure 2, an application on 'myhost' issues
-   the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
-   ai_flags=AI_ALL|AI_V4MAPPED.  LLMNR requests will be sent from both
-   interfaces and the resolver library will return a list containing
-   multiple addrinfo structures, each with an associated sockaddr_in6
-   structure.  This list will thus contain the IPv4 and IPv6 addresses
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 19]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   of both hosts responding to the name 'A'.  Link-local addresses will
-   have a sin6_scope_id value that disambiguates which interface is used
-   to reach the address.  Of course, to the application, Figures 2 and 3
-   are still indistinguishable, but this API allows the application to
-   communicate successfully with any address in the list.
-
-5.  Security Considerations
-
-   LLMNR is by nature a peer-to-peer name resolution protocol. It is
-   therefore inherently more vulnerable than DNS, since existing DNS
-   security mechanisms are difficult to apply to LLMNR. While tools
-   exist to alllow an attacker to spoof a response to a DNS query,
-   spoofing a response to an LLMNR query is easier since the query is
-   sent to a link-scope multicast address, where every host on the
-   logical link will be made aware of it.
-
-   In order to address the security vulnerabilities, the following
-   mechanisms are contemplated:
-
-      [1]  Scope restrictions.
-      [2]  Usage restrictions.
-      [3]  Cache and port separation.
-      [4]  Authentication.
-
-   These techniques are described in the following sections.
-
-5.1.  Scope restriction
-
-   With LLMNR it is possible that hosts will allocate conflicting names
-   for a period of time, or that attackers will attempt to deny service
-   to other hosts by allocating the same name. Such attacks also allow
-   hosts to receive packets destined for other hosts.
-
-   Since LLMNR is typically deployed in situations where no trust model
-   can be assumed, it is likely that LLMNR queries and responses will be
-   unauthenticated.  In the absence of authentication, LLMNR reduces the
-   exposure to such threats by utilizing UDP queries sent to a link-
-   scope multicast address, as well as setting the TTL (IPv4) or Hop
-   Limit (IPv6) fields to one (1) on TCP queries and responses.
-
-   Using a TTL of one (1) to set up a TCP connection in order to send a
-   unicast LLMNR query reduces the likelihood of both denial of service
-   attacks and spoofed responses.  Checking that an LLMNR query is sent
-   to a link-scope multicast address should prevent spoofing of
-   multicast queries by off-link attackers.
-
-   While this limits the ability of off-link attackers to spoof LLMNR
-   queries and responses, it does not eliminate it. For example, it is
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 20]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   possible for an attacker to spoof a response to a frequent query
-   (such as an A or AAAA query for a popular Internet host), and by
-   using a TTL or Hop Limit field larger than one (1), for the forged
-   response to reach the LLMNR sender.
-
-   When LLMNR queries are sent to a link-scope multicast address, it is
-   possible that some routers may not properly implement link-scope
-   multicast, or that link-scope multicast addresses may leak into the
-   multicast routing system.
-
-   Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than
-   one in an LLMNR UDP response may enable denial of service attacks
-   across the Internet.  However, since LLMNR responders only respond to
-   queries for which they are authoritative, and LLMNR does not provide
-   wildcard query support, it is believed that this threat is minimal.
-
-   There also are scenarios such as public "hotspots" where attackers
-   can be present on the same link.  These threats are most serious in
-   wireless networks such as 802.11, since attackers on a wired network
-   will require physical access to the home network, while wireless
-   attackers may reside outside the home.  Link-layer security can be of
-   assistance against these threats if it is available.
-
-5.2.  Usage restriction
-
-   As noted in Sections 2 and 3, LLMNR is intended for usage in a
-   limited set of scenarios.
-
-   If an LLMNR query is sent whenever a DNS server does not respond in a
-   timely way, then an attacker can poison the LLMNR cache by responding
-   to the query with incorrect information.  To some extent, these
-   vulnerabilities exist today, since DNS response spoofing tools are
-   available that can allow an attacker to respond to a query more
-   quickly than a distant DNS server.
-
-   Since LLMNR queries are sent and responded to on the local-link, an
-   attacker will need to respond more quickly to provide its own
-   response prior to arrival of the response from a legitimate
-   responder. If an LLMNR query is sent for an off-link host, spoofing a
-   response in a timely way is not difficult, since a legitimate
-   response will never be received.
-
-   The vulnerability is more serious if LLMNR is given higher priority
-   than DNS among the enabled name resolution mechanisms. In such a
-   configuration, a denial of service attack on the DNS server would not
-   be necessary in order to poison the LLMNR cache, since LLMNR queries
-   would be sent even when the DNS server is available. In addition, the
-   LLMNR cache, once poisoned, would take precedence over the DNS cache,
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 21]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-   eliminating the benefits of cache separation. As a result, LLMNR is
-   only used as a name resolution mechanism of last resort.
-
-5.3.  Cache and port separation
-
-   In order to prevent responses to LLMNR queries from polluting the DNS
-   cache, LLMNR implementations MUST use a distinct, isolated cache for
-   LLMNR on each interface. The use of separate caches is most effective
-   when LLMNR is used as a name resolution mechanism of last resort,
-   since this minimizes the opportunities for poisoning the LLMNR cache,
-   and decreases reliance on it.
-
-   LLMNR operates on a separate port from DNS, reducing the likelihood
-   that a DNS server will unintentionally respond to an LLMNR query.
-
-5.4.  Authentication
-
-   LLMNR implementations may not support DNSSEC or TSIG, and as a
-   result, responses to LLMNR queries may be unauthenticated.  If
-   authentication is desired, and a pre-arranged security configuration
-   is possible, then IPsec ESP with a null-transform MAY be used to
-   authenticate LLMNR responses.  In a small network without a
-   certificate authority, this can be most easily accomplished through
-   configuration of a group pre-shared key for trusted hosts.
-
-6.  IANA Considerations
-
-   This specification creates one new name space:  the reserved bits in
-   the LLMNR header.  These are allocated by IETF Consensus, in
-   accordance with BCP 26 [RFC2434].
-
-   LLMNR requires allocation of port 5355 for both TCP and UDP.
-
-   LLMNR requires allocation of link-scope multicast IPv4 address
-   224.0.0.252, as well as link-scope multicast IPv6 address
-   FF02:0:0:0:0:0:1:3.
-
-7.  References
-
-7.1.  Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
-          Specification", RFC 1035, November 1987.
-
-[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-          April 1992.
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 22]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-          Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
-          Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-          RFC 2308, March 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
-          2365, July 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
-          Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
-          Considerations Section in RFCs", BCP 26, RFC 2434, October
-          1998.
-
-[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
-          (IPv6) Specification", RFC 2460, December 1998.
-
-[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-          2535, March 1999.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
-          August 1999.
-
-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
-          Timer", RFC 2988, November 2000.
-
-7.2.  Informative References
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
-          Fixes", RFC 1536, October 1993.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-          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.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
-          RFC 2292, February 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
-          Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 23]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
-          2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
-          IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
-          Caching", IEEE/ACM Transactions on Networking, Volume 10,
-          Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
-          unicast addresses to communicate with recursive DNS servers",
-          Internet draft (work in progress), draft-ietf-ipv6-dns-
-          discovery-07.txt, October 2002.
-
-[IPV4Link]
-          Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
-          of IPv4 Link-Local Addresses", Internet draft (work in
-          progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, May
-          2004.
-
-[POSIX]   IEEE Std. 1003.1-2001 Standard for Information Technology --
-          Portable Operating System Interface (POSIX). Open Group
-          Technical Standard: Base Specifications, Issue 6, December
-          2001.  ISO/IEC 9945:2002.  http://www.opengroup.org/austin
-
-[LLMNREnable]
-          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
-          in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[NodeInfo]
-          Crawford, M., "IPv6 Node Information Queries", Internet draft
-          (work in progress), draft-ietf-ipn-gwg-icmp-name-
-          lookups-09.txt, May 2002.
-
-Acknowledgments
-
-   This work builds upon original work done on multicast DNS by Bill
-   Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
-   grant #F30602-99-1-0523. The authors gratefully acknowledge their
-   contribution to the current specification.  Constructive input has
-   also been received from Mark Andrews, Stuart Cheshire, Randy Bush,
-   Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik
-   Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik
-   Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill,
-   Keith Moore and Markku Savela.
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 24]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-Authors' Addresses
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   EMail: levone@microsoft.com
-
-   Bernard Aboba
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   Phone: +1 425 706 6605
-   EMail: bernarda@microsoft.com
-
-   Dave Thaler
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   Phone: +1 425 703 8835
-   EMail: dthaler@microsoft.com
-
-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.
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 25]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                     18 July 2004
-
-
-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.
-
-Open Issues
-
-   Open issues with this specification are tracked on the following web
-   site:
-
-   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler       Standards Track                   [Page 26]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt
deleted file mode 100644
index c5c3b84ba3d5..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt
+++ /dev/null
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group                                        Yuji Kamite
-INTERNET-DRAFT                                       NTT Communications
-<draft-ietf-dnsext-tkey-renewal-mode-04.txt>            Masaya Nakayama
-Expires: Aug. 2004                              The University of Tokyo
-                                                              Feb. 2004
-
-
-
-
-                      TKEY Secret Key Renewal Mode
-
-
-Status of this Memo
-
-  This document is an Internet-Draft and is in full conformance with all
-  provisions of Section 10 of RFC2026.
-
-  Internet-Drafts are working documents of the Internet Engineering Task
-  Force (IETF), its areas, and its working groups.  Note that other
-  groups may also distribute working documents as Internet-Drafts.
-
-  Internet-Drafts are draft documents valid for a maximum of six months
-  and may be updated, replaced, or obsoleted by other documents at any
-  time.  It is inappropriate to use Internet-Drafts as reference
-  material or to cite them other than as ``work in progress.''
-
-  The list of current Internet-Drafts can be accessed at
-  http://www.ietf.org/ietf/1id-abstracts.txt
-
-  The list of Internet-Draft Shadow Directories can be accessed at
-  http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document defines a new mode in TKEY and proposes an atomic
-   method for changing secret keys used for TSIG periodically.
-   Originally, TKEY provides methods of setting up shared secrets other
-   than manual exchange, but it cannot control timing of key renewal
-   very well though it can add or delete shared keys separately. This
-   proposal is a systematical key renewal procedure intended for
-   preventing signing DNS messages with old and non-safe keys
-   permanently.
-
-
-
-
-
-
-
-
-Kamite, et. al.                                                 [Page 1]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-                           Table of Contents
-
-
-1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-  1.1  Defined Words . . . . . . . . . . . . . . . . . . . . . . . .   3
-  1.2  New Format and Assigned Numbers . . . . . . . . . . . . . . .   4
-  1.3  Overview of Secret Key Renewal Mode . . . . . . . . . . . . .   4
-2  Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . .   5
-  2.1  Key Usage Time Check  . . . . . . . . . . . . . . . . . . . .   5
-  2.2  Partial Revocation  . . . . . . . . . . . . . . . . . . . . .   6
-  2.3  Key Renewal Message Exchange  . . . . . . . . . . . . . . . .   7
-    2.3.1  Query for Key Renewal . . . . . . . . . . . . . . . . . .   7
-    2.3.2  Response for Key Renewal  . . . . . . . . . . . . . . . .   7
-    2.3.3  Attributes of Generated Key . . . . . . . . . . . . . . .   8
-    2.3.4  TKEY RR structure . . . . . . . . . . . . . . . . . . . .   8
-  2.4  Key Adoption  . . . . . . . . . . . . . . . . . . . . . . . .  10
-    2.4.1  Query for Key Adoption  . . . . . . . . . . . . . . . . .  10
-    2.4.2  Response for Key Adoption . . . . . . . . . . . . . . . .  10
-  2.5  Keying Schemes  . . . . . . . . . . . . . . . . . . . . . . .  11
-    2.5.1  DH Exchange for Key Renewal . . . . . . . . . . . . . . .  11
-    2.5.2  Server Assigned Keying for Key Renewal  . . . . . . . . .  12
-    2.5.3  Resolver Assigned Keying for Key Renewal  . . . . . . . .  13
-  2.6  Considerations about Non-compliant Hosts  . . . . . . . . . .  14
-3  Secret Storage  . . . . . . . . . . . . . . . . . . . . . . . . .  15
-4  Compulsory Key Revocation . . . . . . . . . . . . . . . . . . . .  15
-  4.1  Compulsory Key Revocation by Server . . . . . . . . . . . . .  15
-  4.2  Authentication Methods Considerations . . . . . . . . . . . .  15
-5  Special Considerations for Two Servers' Case  . . . . . . . . . .  16
-  5.1  To Cope with Collisions of Renewal Requests . . . . . . . . .  16
-6  Key Name Considerations . . . . . . . . . . . . . . . . . . . . .  17
-7  Example Usage of Secret Key Renewal Mode  . . . . . . . . . . . .  17
-8  Security Considerations . . . . . . . . . . . . . . . . . . . . .  20
-9  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . .  20
-10 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . .  21
-11 References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
-Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . .  22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.                                                 [Page 2]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-1.  Introduction
-
-   TSIG [RFC2845] provides DNS message integrity and the
-   request/transaction authentication by means of message authentication
-   codes (MAC). TSIG is a practical solution in view of calculation
-   speed and availability. However, TSIG does not have exchanging
-   mechanism of shared secret keys between server and resolver, and
-   administrators might have to exchange secret keys manually. TKEY
-   [RFC2930] is introduced to solve such problem and it can exchange
-   secrets for TSIG via networks.
-
-   In various modes of TKEY, a server and a resolver can add or delete a
-   secret key be means of TKEY message exchange. However, the existing
-   TKEY does not care fully about the management of keys which became
-   too old, or dangerous after long time usage.
-
-   It is ideal that the number of secret which a pair of hosts share
-   should be limited only one, because having too many keys for the same
-   purpose might not only be a burden to resolvers for managing and
-   distinguishing according to servers to query, but also does not seem
-   to be safe in terms of storage and protection against attackers.
-   Moreover, perhaps holding old keys long time might give attackers
-   chances to compromise by scrupulous calculation.
-
-   Therefore, when a new shared secret is established by TKEY, the
-   previous old secret should be revoked immediately. To accomplish
-   this, DNS servers must support a protocol for key renewal. This
-   document specifies procedure to refresh secret keys between two hosts
-   which is defined within the framework of TKEY, and it is called "TKEY
-   Secret Key Renewal Mode".
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
-   "OPTIONAL" in this document are to be interpreted as described in
-   [RFC2119].
-
-
-1.1.  Defined Words
-
-   * Inception Time: Beginning of the shared secret key lifetime. This
-   value is determined when the key is generated.
-
-   * Expiry Limit: Time limit of the key's validity. This value is
-   determined when a new key is generated. After Expiry Limit, server
-   and client (resolver) must not authenticate TSIG signed with the key.
-   Therefore, Renewal to the next key should be carried out before
-   Expiry Limit.
-
-   * Partial Revocation Time: Time when server judges the key is too old
-
-
-
-Kamite, et. al.                                                 [Page 3]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   and must be updated. It must be between Inception Time and Expiry
-   Limit.  This value is determined by server freely following its
-   security policy. e.g., If the time from Inception to Partial
-   Revocation is short, renewal will be carried out more often, which
-   might be safer.
-
-   * Revocation Time: Time when the key becomes invalid and can be
-   removed. This value is not determined in advance because it is the
-   actual time when revocation is completed.
-
-   * Adoption Time: Time when the new key is adopted as the next key
-   formally. After Adoption, the key is valid and server and client can
-   generate or verify TSIG making use of it. Adoption Time also means
-   the time when it becomes possible to remove the previous key, so
-   Revocation and Adoption are usually done at the same time.
-
-
-                  Partial
-    Inception     Revocation    Revocation         Expiry Limit
-     |                |              |             |
-     |----------------|- - - - - - >>|- (revoked) -|
-     |                |              |             |
-    previous key      |      |       |
-                             |- - - -|-------------------->> time
-                             |       |               new key
-                         Inception   Adoption
-
-
-1.2.  New Format and Assigned Numbers
-
-   TSIG
-         ERROR = (PartialRevoke), TBD
-
-   TKEY
-         Mode  = (server assignment for key renewal), TBD
-         Mode  = (Diffie-Hellman exchange for key renewal), TBD
-         Mode  = (resolver assignment for key renewal), TBD
-         Mode  = (key adoption), TBD
-
-
-1.3.  Overview of Secret Key Renewal Mode
-
-   When a server receives a query from a client signed with a TSIG key,
-   It always checks if the present time is within the range of usage
-   duration it considers safe. If it is judged that the key is too old,
-   i.e., after Partial Revocation Time, the server comes to be in
-   Partial Revocation state about the key, and this key is called
-   partially revoked.
-
-
-
-Kamite, et. al.                                                 [Page 4]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   In this state, if a client sends a normal query (e.g., question about
-   A RR) other than TKEY Renewal request with TSIG signed with the old
-   key, the server returns an error message to notify that the time to
-   renew has come. This is called "PartialRevoke" error message. It is
-   server's choice whether it returns PartialRevoke or not. If and only
-   if the server is ready for changing its own key, it decides to return
-   PartialRevoke.
-
-   The client which got this error is able to notice that it is
-   necessary to refresh the secret. To make a new shared secret, it
-   sends a TKEY Renewal request, in which several keying methods are
-   available. It can make use of TSIG authentication signed with the
-   partially revoked key mentioned above.
-
-   After new secret establishment, the client sends a TKEY Adoption
-   request for renewal confirmation. This can also be authenticated with
-   the partially revoked key. If this is admitted by the server, the new
-   key is formally adopted, and at the same time the corresponding old
-   secret is invalidated. Then the client can send the first query again
-   signed with the new key.
-
-   Key renewal procedure is executed based on two-phase commit
-   mechanism. The first phase is the TKEY Renewal request and its
-   response, which means preparatory confirmation for key update. The
-   second phase is Adoption request and its response. If the server gets
-   request and client receives the response successfully, they can
-   finish renewal process. If any error happens and renewal process
-   fails during these phases, client should roll back to the beginning
-   of the first phase, and send TKEY Renewal request again. This
-   rollback can be done until the Expiry Limit of the key.
-
-
-2.  Shared Secret Key Renewal
-
-   Suppose a server and a client agree to change their TSIG keys
-   periodically. Key renewal procedure is defined between two hosts.
-
-2.1.  Key Usage Time Check
-
-   Whenever a server receives a query with TSIG and can find a key that
-   is used for signing it, the server checks its Inception Time, Partial
-   Revocation Time and Expiry Limit (this information is usually
-   memorized by the server).
-
-   When the present time is before Inception Time, the server MUST NOT
-   verify TSIG with the key, and server acts the same way as when the
-   key used by the client is not recognized. It follows [RFC2845] 4.5.1.
-
-
-
-
-Kamite, et. al.                                                 [Page 5]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   When the present time is equal to Inception Time, or between
-   Inception Time and Partial Revocation Time, the behavior of the
-   server is the same as when a valid key is found. It follows [RFC2845]
-   4.5.2 and 4.5.3.
-
-   When the present time is the same as the Partial Revocation Time, or
-   between the Partial Revocation Time and Expiry Limit, the server
-   comes to be in Partial Revocation state about the TSIG key and
-   behaves according to the next section.
-
-   When the present time is the same as the Expiry Time or after it, the
-   server MUST NOT verify TSIG with the key, and returns error messages
-   in the same way as when the key used by the client is not recognized.
-   It follows [RFC2845] 4.5.1.
-
-
-2.2.  Partial Revocation
-
-   In Partial Revocation state, we say the server has partially revoked
-   the key and the key has become a "partially revoked key".
-
-   If server has received a query signed with the partially revoked key
-   for TKEY Renewal request (See section 2.3.) or Key Adoption request
-   (See section 2.4.), then server does proper process following each
-   specification. If it is for TKEY key deletion request ([RFC2930]
-   4.2), server MAY process usual deletion operation defined therein.
-
-   If server receives other types of query signed with the partially
-   revoked key, and both the corresponding MAC and signed TIME are
-   verified, then server begins returning answer whose TSIG error code
-   is "PartialRevoke" (See section 9.). Server MUST randomly but with
-   increasing frequency return PartialRevoke when in the Partial
-   Revocation state.
-
-   Server can decide when it actually sends PartialRevoke, checking if
-   it is appropriate time for renewal. Server MUST NOT return
-   PartialRevoke if this is apart long lived TSIG transaction (such as
-   AXFR) that started before the Partial Revocation Time.
-
-   If the client receives PartialRevoke and understands it, then it MUST
-   retry the query with the old key unless a new key has been adopted.
-   Client SHOULD start the process to renew the TSIG key. For key
-   renewal procedure, see details in Section 2.3 and 2.4.
-
-   PartialRevoke period (i.e., time while server returns PartialRevoke
-   randomely) SHOULD be small, say 2-5% of key lifetime. This is
-   server's choice.
-
-
-
-
-Kamite, et. al.                                                 [Page 6]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   Server MUST keep track of clients ignoring PartialRevoke, thus
-   indicating ignorance of this TKEY mode.
-
-   PartialRevoke error messages have the role to inform clients of the
-   keys' partial revocation and urge them to send TKEY Renewal requests.
-   These error responses MUST be signed with those partial revoked keys
-   if the queries are signed with them. They are sent only when the
-   signing keys are found to be partially revoked. If the MAC of TSIG
-   cannot be verified with the partially revoked keys, servers MUST NOT
-   return PartialRevoke error with MAC, but MUST return another error
-   such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
-   words, a server informs its key's partial revocation only when the
-   MAC in the received query is valid.
-
-
-2.3.  Key Renewal Message Exchange
-
-2.3.1.  Query for Key Renewal
-
-   If a client has received a PartialRevoke error and authenticated the
-   response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
-   this document, we call it Renewal request, too.) to the server. The
-   request MUST be signed with TSIG or SIG(0) [RFC2931] for
-   authentication. If TSIG is selected, the client can sign it with the
-   partial revoked key.
-
-   Key Renewal can use one of several keying methods which is indicated
-   in "Mode" field of TKEY RR, and its message structure is dependent on
-   that method.
-
-
-2.3.2.  Response for Key Renewal
-
-   The server which has received Key Renewal request first tries to
-   verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
-   verified with the partially revoked key, the request MUST be
-   authenticated.
-
-   After authentication, server must check existing old key's validity.
-   If the partially revoked key indicated in the request TKEY's OldName
-   and OldAlgorithm field (See section 2.3.4.) does not exist at the
-   server, "BADKEY" [RFC2845] is given in Error field for response. If
-   any other error happens, server returns appropriate error messages
-   following the specification described in section 2.5. If there are no
-   errors, server returns a Key Renewal answer. This answer MUST be
-   signed with TSIG or SIG(0) for authentication.
-
-   When this answer is successfully returned and no error is detected by
-
-
-
-Kamite, et. al.                                                 [Page 7]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   client, a new shared secret can be established. The details of
-   concrete keying procedure are given in the section 2.5.
-
-   Note:
-      Sometimes Adoption message and new Renewal request will cross on
-      the wire. In this case the newly generated key Adoption message is
-      resent.
-
-
-2.3.3.  Attributes of Generated Key
-
-   As a result of this message exchange, client comes to know the newly
-   generated key's attributes such as key's name, Inception Time and
-   Expiry Limit. They are decided by the server and told to the client;
-   in particular, however, once the server has decided Expiry Limit and
-   returned a response, it should obey the decision as far as it can. In
-   other words, they SHOULD NOT change time values for checking Expiry
-   Limit in the future without any special reason, such as security
-   issue like "Emergency Compulsory Revocation" described in section 8.
-
-   On the other hand, Partial Revocation Time of this generated key is
-   not decided based on the request, and not informed to the client. The
-   server can determine any value as long as it is between Inception
-   Time and Expiry Limit. However, the period from Inception to Partial
-   Revocation SHOULD be fixed as the server side's configuration or be
-   set the same as the corresponding old key's one.
-
-   Note:
-      Even if client sends Key Renewal request though the key described
-      in OldName has not been partially revoked yet, server does renewal
-      processes.  At the moment when the server accepts such requests
-      with valid authentication, it MUST forcibly consider the key is
-      already partially revoked, that is, the key's Partial Revocation
-      Time must be changed into the present time (i.e., the time when
-      the server receives the request).
-
-
-2.3.4.  TKEY RR structure
-
-   TKEY RR for Key Renewal message has the structure given below. In
-   principle, format and definition for each field follows [RFC2930].
-   Note that each keying scheme sometimes needs different interpretation
-   of RDATA field; for detail, see section 2.5.
-
-        Field        Type         Comment
-        -------      ------       -------
-        NAME         domain       used for a new key, see below
-        TYPE         u_int16_t    (defined in [RFC2930])
-
-
-
-Kamite, et. al.                                                 [Page 8]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-        CLASS        u_int16_t    (defined in [RFC2930])
-        TTL          u_int32_t    (defined in [RFC2930])
-        RDLEN        u_int16_t    (defined in [RFC2930])
-        RDATA:
-         Algorithm:   domain       algorithm for a new key
-         Inception:   u_int32_t    about the keying material
-         Expiration:  u_int32_t    about the keying material
-         Mode:        u_int16_t    scheme for key agreement
-                                   see section 9.
-         Error:       u_int16_t    see description below
-         Key Size:    u_int16_t    see description below
-         Key Data:    octet-stream
-         Other Size:  u_int16_t    (defined in [RFC2930])
-                                   size of other data
-         Other Data:               newly defined: see description below
-
-
-     For "NAME" field, both non-root and root name are allowed. It may
-     be used for a new key's name in the same manner as [RFC2930] 2.1.
-
-     "Algorithm" specifies which algorithm is used for agreed keying
-     material, which is used for identification of the next key.
-
-     "Inception" and "Expiration" are used for the valid period of
-     keying material. The meanings differ somewhat according to whether
-     the message is request or answer, and its keying scheme.
-
-     "Key Data" has different meanings according to keying schemes.
-
-     "Mode" field stores the value in accordance with the keying method,
-     and see section 2.5. Servers and clients supporting TKEY Renewal
-     method MUST implement "Diffie-Hellman exchange for key renewal"
-     scheme. All other modes are OPTIONAL.
-
-     "Error" is an extended RCODE which includes "PartialRevoke" value
-     too. See section 9.
-
-     "Other Data" field has the structure given below.  They describe
-     attributes of the key to be renewed.
-
-        in Other Data filed:
-
-          Field          Type     Comment
-          -------        ------   -------
-          OldNAME        domain   name of the old key
-          OldAlgorithm   domain   algorithm of the old key
-
-
-
-
-
-Kamite, et. al.                                                 [Page 9]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-          "OldName" indicates the name of the previous key (usually,
-          this is partially revoked key's name that client noticed by
-          PartialRevoke answer from server), and "OldAlogirthm"
-          indicates its algorithm.
-
-
-2.4.  Key Adoption
-
-2.4.1.  Query for Key Adoption
-
-   After receiving a TKEY Renewal answer, the client gets the same
-   secret as the server. Then, it sends a TKEY Adoption request. The
-   request's question section's QNAME field is the same as the NAME
-   filed of TKEY written below. In additional section, there is one TKEY
-   RR that has the structure and values described below.
-
-     "NAME" field is the new key's name to be adopted which was already
-     generated by Renewal message exchange. "Algorithm" is its
-     algorithm. "Inception" means the key's Inception Time, and
-     "Expiration" means Expiry Limit.
-
-     "Mode" field is the value of "key adoption". See section 9.
-
-     "Other Data" field in Adoption has the same structure as that of
-     Renewal request message. "OldName" means the previous old key, and
-     "OldAlogirthm" means its algorithm.
-
-   Key Adoption request MUST be signed with TSIG or SIG(0) for
-   authentication. The client can sign TSIG with the previous key. Note
-   that until Adoption is finished, the new key is treated as invalid,
-   thus it cannot be used for authentication immediately.
-
-
-2.4.2.  Response for Key Adoption
-
-   The server which has received Adoption request, it verifies TSIG or
-   SIG(0) accompanying it. If the TSIG is signed with the partially
-   revoked key and can be verified, the message MUST be authenticated.
-
-   If the next new key indicated by the request TKEY's "NAME" is not
-   present at the server, BADNAME [RFC2845] is given in Error field and
-   the error message is returned.
-
-   If the next key exists but it has not been adopted formally yet, the
-   server confirms the previous key's existence indicated by the
-   "OldName" and "OldAlgorithm" field. If it succeeds, the server
-   executes Adoption of the next key and Revocation of the previous key.
-   Response message duplicates the request's TKEY RR with NOERROR,
-
-
-
-Kamite, et. al.                                                [Page 10]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   including "OldName" and "OldAlgorithm" that indicate the revoked key.
-
-   If the next key exists but it is already adopted, the server returns
-   a response message regardless of the substance of the request TKEY's
-   "OldName". In this response, Response TKEY RR has the same data as
-   the request's one except as to its "Other Data" that is changed into
-   null (i.e., "Other Size" is zero), which is intended for telling the
-   client that the previous key name was ignored, and the new key is
-   already available.
-
-   Client sometimes has to retry Adoption request. Suppose the client
-   sent request signed with the partially revoked key, but its response
-   did not return successfully (e.g., due to the drop of UDP packet).
-   Client will probably retry Adoption request; however, the request
-   will be refused in the form of TSIG "BADKEY" error because the
-   previous key was already revoked. In this case, client will
-   retransmit Adoption request signed with the next key, and expect a
-   response which has null "Other Data" for confirming the completion of
-   renewal.
-
-
-2.5.  Keying Schemes
-
-   In Renewal message exchanges, there are no limitations as to which
-   keying method is actually used. The specification of keying
-   algorithms is independent of the general procedure of Renewal that is
-   described in section 2.3.
-
-   Now this document specifies three algorithms in this section, but
-   other future documents can make extensions defining other methods.
-
-
-2.5.1.  DH Exchange for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.1. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as keying material
-   computation, are the exactly same as the specification of [RFC2930]
-   4.1.
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. KEY RR is
-      the client's Diffie-Hellman public key [RFC2539].
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-
-
-
-Kamite, et. al.                                                [Page 11]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-      TKEY "Mode" field stores the value of "DH exchange for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3. If
-      any incompatible DH key is found in the request, "BADKEY"
-      [RFC2845] is given in Error field for response. "FORMERR" is given
-      if the query included no DH KEY.
-
-      If there are no errors, the server processes a response according
-      to Diffie-Hellman algorithm and returns the answer. In this
-      answer, there is one TKEY RR in answer section and KEY RR(s) in
-      additional section.
-
-      As long as no error has occurred, all values of TKEY are equal to
-      that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
-      Inception, Expiration, Key Size and Key Data.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-      TKEY "Key Data" is used as an additional nonce, following
-      [RFC2930] 4.1.
-
-      The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
-      the additional section and a server Diffie-Hellman KEY RR will
-      also be present in the answer section, following [RFC2930] 4.1.
-
-
-2.5.2.  Server Assigned Keying for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.4. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as secret encrypting
-   method, are the exactly same as the specification of [RFC2930] 4.4.
-
-
-
-Kamite, et. al.                                                [Page 12]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. KEY RR is
-      used in encrypting the response.
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-      TKEY "Mode" field stores the value of "server assignment for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is provided following the specification of
-      [RFC2930] 4.4.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3.
-      "FORMERR" is given if the query specified no encryption key.
-
-      If there are no errors, the server response contains one TKEY RR
-      in the answer section, and echoes the KEY RR provided in the query
-      in the additional information section.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-      TKEY "Key Data" is the assigned keying data encrypted under the
-      public key in the resolver provided KEY RR, which is the same as
-      [RFC2930] 4.4.
-
-
-2.5.3.  Resolver Assigned Keying for Key Renewal
-
-   This scheme is defined as an extended method of [RFC2930] 4.5. This
-   specification only describes the difference from it and special
-   notice; assume that all other points, such as secret encrypting
-   method, are the exactly same as the specification of [RFC2930] 4.5.
-
-
-
-
-Kamite, et. al.                                                [Page 13]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   Query
-      In Renewal request for type TKEY with this mode, there is one TKEY
-      RR and one KEY RR in the additional information section. TKEY RR
-      has the encrypted keying material and KEY RR is the server public
-      key used to encrypt the data.
-
-      QNAME in question section is the same as that of "NAME" field in
-      TKEY RR, i.e., it means the requested new key's name.
-
-      TKEY "Mode" field stores the value of "resolver assignment for key
-      renewal". See section 9.
-
-      TKEY "Inception" and "Expiration" are those requested for the
-      keying material, that is, requested usage period of a new key.
-
-      TKEY "Key Data" is the encrypted keying material.
-
-   Response
-      The server which received this request first verifies the TSIG,
-      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
-      old key's existence validity is checked, following section 2.3.
-      "FORMERR" is given if the server does not have the corresponding
-      private key for the KEY RR that was shown sin the request.
-
-      If there are no errors, the server returns a response. The
-      response contains a TKEY RR in the answer section to tell the
-      shared key's name and its usage time values.
-
-      TKEY "NAME" field in the answer specifies the name of newly
-      produced key which the client MUST use.
-
-      TKEY "Inception" and "Expiration" mean the periods of the produced
-      key usage. "Inception" is set to be the time when the new key is
-      actually generated or the time before it, and it will be regarded
-      as Inception Time. "Expiration" is determined by the server, and
-      it will be regarded as Expiry Limit.
-
-
-2.6.  Considerations about Non-compliant Hosts
-
-   Key Renewal requests and responses must be exchanged between hosts
-   which can understand them and do proper processes. PartialRevoke
-   error messages will be only ignored if they should be returned to
-   non-compliant hosts.
-
-   Note that server does not inform actively the necessity of renewal to
-   clients, but inform it as responses invoked by client's query.
-   Server needs not care whether the PartialRevoke errors has reached
-
-
-
-Kamite, et. al.                                                [Page 14]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   client or not. If client has not received yet because of any reasons
-   such as packet drops, it will resend the queries, and finally will be
-   able to get PartialRevoke information.
-
-
-3.  Secret Storage
-
-   Every server keeps all secrets and attached information, e.g.,
-   Inception Time, Expiry Limit, etc. safely to be able to recover from
-   unexpected stop. To accomplish this, formally adopted keys SHOULD be
-   memorized not only on memory, but also be stored in the form of some
-   files. It will become more secure if they are stored in ecrypted
-   form.
-
-
-4.  Compulsory Key Revocation
-
-4.1.  Compulsory Key Revocation by Server
-
-   There is a rare but possible case that although servers have already
-   partially revoked keys, clients do not try to send any Renewal
-   requests. If this state continues, in the future it will become the
-   time of Expiry Limit. After Expiry Limit, the keys will be expired
-   and completely removed, so this is called Compulsory Key Revocation
-   by server.
-
-   If Expiry Limit is too distant from the Partial Revocation Time, then
-   even though very long time passes, clients will be able to refresh
-   secrets only if they add TSIG signed with those old partially revoked
-   keys into requests, which is not safe.
-
-   On the other hand, if Expiry Limit is too close to Partial Revocation
-   Time, perhaps clients might not be able to notice their keys' Partial
-   Revocation by getting "PartialRevoke" errors.
-
-   Therefore, servers should set proper Expiry Limit to their keys,
-   considering both their keys' safety, and enough time for clients to
-   send requests and process renewal.
-
-
-4.2.  Authentication Methods Considerations
-
-   It might be ideal to provide both SIG(0) and TSIG as authentication
-   methods. For example:
-
-     A client and a server start SIG(0) authentication at first, to
-     establish TSIG shared keys by means of "Query for Diffie-Hellman
-     Exchanged Keying" as described in [RFC2930] 4.1. Once they get
-
-
-
-Kamite, et. al.                                                [Page 15]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-     shared secret, they keep using TSIG for queries and responses.
-     After a while the server returns a "ParitalRevoke" error and they
-     begin a key renewal process. Both TSIG signed with partially
-     revoked keys and SIG(0) are okay for authentication, but TSIG would
-     be easier to use considering calculation efficiency.
-
-     Suppose now client is halted for long time with some reason.
-     Because server does not execute any renewal process, it will
-     finally do Compulsory Revocation. Even if client restarts and sends
-     a key Renewal request, it will fail because old key is already
-     deleted at server.
-
-     At this moment, however, if client also uses SIG(0) as another
-     authentication method, it can make a new shared key again and
-     recover successfully by sending "Query for Diffie-Hellman Exchanged
-     Keying" with SIG(0).
-
-
-5.  Special Considerations for Two servers' Case
-
-   This section refers to the case where both hosts are DNS servers
-   which can act as full resolvers as well and using one shared key
-   only. If one server (called Server A) wants to refresh a shared key
-   (called "Key A-B"), it will await a TKEY Renewal request from the
-   other server (called Server B). However, perhaps Server A wants to
-   refresh the key right now.
-
-   In this case, Server A is allowed to send a Renewal request to Server
-   B, if Server A knows the Key A-B is too old and wants to renew it
-   immediately.
-
-   Note that the initiative in key renewal belongs to Server A because
-   it can notice the Partial Revocation Time and decide key renewal. If
-   Server B has information about Partial Revocation Time as well, it
-   can also decide for itself to send Renewal request to Server A.
-   However, it is not essential for both two servers have information
-   about key renewal timing.
-
-5.1.  To Cope with Collisions of Renewal Requests
-
-   At least one of two hosts which use Key Renewal must know their key
-   renewal information such as Partial Revocation Time. It is okay that
-   both hosts have it.
-
-   Provided that both two servers know key renewal timing information,
-   there is possibility for them to begin partial revocation and sending
-   Renewal requests to each other at the same time. Such collisions will
-   not happen so often because Renewal requests are usually invoked when
-
-
-
-Kamite, et. al.                                                [Page 16]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-   hosts want to send queries, but it is possible.
-
-   When one of two servers tries to send Renewal requests, it MUST
-   protect old secrets that it has partially revoked and prevent it from
-   being refreshed by any requests from the other server (i.e., it must
-   lock the old secret during the process of renewal). While the server
-   is sending Renewal requests and waiting responses, it ignores the
-   other server's Renewal requests.
-
-   Therefore, servers might fail to change secrets by means of their own
-   requests to others. After failure they will try to resend, but they
-   should wait for random delays by the next retries. If they get any
-   Renewal requests from others while they are waiting, their shared
-   keys may be refreshed, then they do not need to send any Renewal
-   requests now for themselves.
-
-
-6.  Key Name Considerations
-
-   Since both servers and clients have only to distinguish new secrets
-   and old ones, keys' names do not need to be specified strictly.
-   However, it is recommended that some serial number or key generation
-   time be added to the name and that the names of keys between the same
-   pair of hosts should have some common labels among their keys. For
-   example, suppose A.example.com. and B.example.com. share the key
-   "<serial number>.A.example.com.B.example.com." such as
-   "10010.A.example.com.B.example.com.". After key renewal, they change
-   their secret and name into "10011.A.example.com.B.example.com."
-
-   Servers and clients must be able to use keys properly for each query.
-   Because TSIG secret keys themselves do not have any particular IDs to
-   be distinguished and would be identified by their names and
-   algorithm, it must be understood correctly what keys are refreshed.
-
-
-7.  Example Usage of Secret Key Renewal Mode
-
-   This is an example of Renewal mode usage where a Server,
-   server.example.com, and a Client, client.exmple.com have an initial
-   shared secret key named "00.client.example.com.server.example.com".
-
-     (1) The time values for key
-     "00.client.example.com.server.example.com" was set as follows:
-     Inception Time is at 1:00, Expiry Limit is at 21:00.
-
-     (2) At Server, renewal time has been set: Partial Revocation Time
-     is at 20:00.
-
-
-
-
-Kamite, et. al.                                                [Page 17]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-     (3) Suppose the present time is 19:55. If Client sends a query
-     signed with key "00.client.example.com.server.example.com" to ask
-     the IP address of "www.example.com", finally it will get a proper
-     answer from Server with valid TSIG (NOERROR).
-
-     (4) At 20:05. Client sends a query to ask the IP address of
-     "www2.example.com". It is signed with key
-     "00.client.example.com.server.example.com". Server returns an
-     answer for the IP address. However, server has begun retuning
-     PartialRevoke Error randomely. This answer includes valid TSIG MAC
-     signed with "00.client.example.com.server.example.com", and its
-     Error Code indicates PartialRevoke. Client understands that the
-     current key is partially revoked.
-
-     (5) At 20:06. Client sends a Renewal request to Server. This
-     request is signed with key
-     "00.client.example.com.server.example.com". It includes data such
-     as:
-
-      Question Section:
-         QNAME = 01.client.example.com. (Client can set this freely)
-         TYPE  = TKEY
-
-      Additional Section:
-         01.client.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (DH exchange for key renewal)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-      Additional Section also contains a KEY RR for DH and a TSIG RR.
-
-     (6) As soon as Server receives this request, it verifies TSIG. It
-     is signed with the partially revoked key
-     "00.client.example.com.server.example.com". and Server accepts the
-     request. It creates a new key by Diffie-Hellman calculation and
-     returns an answer which includes data such as:
-
-      Answer Section:
-         01.client.example.com.server.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (DH exchange for key renewal)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-
-
-Kamite, et. al.                                                [Page 18]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-     Answer Section also contains KEY RRs for DH.
-
-      Additional Section also contains a TSIG RR.
-     This response is signed with key
-     "00.client.example.com.server.example.com" without error.
-
-     At the same time, Server decides to set the Partial Revocation Time
-     of this new key "01.client.example.com.server.example.com." as next
-     day's 15:00.
-
-     (7) Client gets the response and checks TSIG MAC, and calculates
-     Diffie-Hellman. It will get a new key, and it has been named
-     "01.client.example.com.server.example.com" by Server.
-
-     (8) At 20:07. Client sends an Adoption request to Server. This
-     request is signed with the previous key
-     "00.client.example.com.server.example.com". It includes:
-
-      Question Section:
-         QNAME = 01.client.example.com.server.example.com.
-         TYPE  = TKEY
-
-      Additional Section:
-         01.client.example.com.server.example.com. TKEY
-          Algorithm    = hmac-md5-sig-alg.reg.int.
-          Inception    = (value meaning 20:00)
-          Expiration   = (value meaning next day's 16:00)
-          Mode         = (key adoption)
-          OldName      = 00.client.example.com.server.example.com.
-          OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-     Additional Section also contains a TSIG RR.
-
-     (9) Server verifies the query's TSIG. It is signed with the
-     previous key and authenticated. It returns a response whose TKEY RR
-     is the same as the request's one. The response is signed with key
-     "00.client.example.com.server.example.com.". As soon as the
-     response is sent, Server revokes and removes the previous key. At
-     the same time, key "01.client.example.com.server.example.com." is
-     validated.
-
-     (10) Client acknowledges the success of Adoption by receiving the
-     response.  Then, it retries to send an original question about
-     "www2.example.com". It is signed with the adopted key
-     "01.client.example.com.server.example.com", so Server authenticates
-     it and returns an answer.
-
-
-
-
-
-Kamite, et. al.                                                [Page 19]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-     (11) This key is used until next day's 15:00. After that, it will
-     be partially revoked again.
-
-
-8.  Security Considerations
-
-   This document considers about how to refresh shared secret. Secret
-   changed by this method is used at servers in support of TSIG
-   [RFC2845].
-
-   [RFC2104] says that current attacks to HMAC do not indicate a
-   specific recommended frequency for key changes but periodic key
-   refreshment is a fundamental security practice that helps against
-   potential weaknesses of the function and keys, and limits the damage
-   of an exposed key. TKEY Secret Key Renewal provides the method of
-   periodical key refreshment.
-
-   In TKEY Secret Key Renewal, clients need to send two requests
-   (Renewal and Adoption) and spend time to finish their key renewal
-   processes. Thus the usage period of secrets should be considered
-   carefully based on both TKEY processing performance and security.
-
-   This document specifies the procedure of periodical key renewal, but
-   actually there is possibility for servers to have no choice other
-   than revoking their secret keys immediately especially when the keys
-   are found to be compromised by attackers. This is called "Emergency
-   Compulsory Revocation". For example, suppose the original Expiry
-   Limit was set at 21:00, Partial Revocation Time at 20:00 and
-   Inception Time at 1:00.  if at 11:00 the key is found to be
-   compromised, the server sets Expiry Limit forcibly to be 11:00 or
-   before it.
-
-   Consequently, once Compulsory Revocation (See section 4.) is carried
-   out, normal renewal process described in this document cannot be done
-   any more as far as the key is concerned. However, after such
-   accidents happened, the two hosts are able to establish secret keys
-   and begin renewal procedure only if they have other (non-compromised)
-   shared TSIG keys or safe SIG(0) keys for the authentication of
-   initial secret establishment such as Diffie-Hellman Exchanged Keying.
-
-
-9.  IANA Considerations
-
-   IANA needs to allocate a value for "DH exchange for key renewal",
-   "server assignment for key renewal", "resolver assignment for key
-   renewal" and "key adoption" in the mode filed of TKEY. It also needs
-   to allocate a value for "PartialRevoke" from the extended RCODE
-   space.
-
-
-
-Kamite, et. al.                                                [Page 20]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-10.  Acknowledgement
-
-   The authors would like to thank Olafur Gudmundsson, whose helpful
-   input and comments contributed greatly to this document.
-
-
-11.  References
-
-[RFC2104]
-     H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
-     Authentication", RFC2104, February 1997.
-
-[RFC2119]
-     Bradner, S., "Key words for use in RFCs to Indicate Requirement
-     Levels", RFC 2119, March 1997.
-
-[RFC2539]
-     D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
-     System (DNS)", RFC 2539, March 1999.
-
-[RFC2845]
-     Vixie, P., Gudmundsson, O., Eastlake, D. and B.  Wellington,
-     "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
-     May 2000.
-
-[RFC2930]
-     D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
-     RFC 2930, September 2000.
-
-[RFC2931]
-     D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
-     )", RFC 2931, September 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.                                                [Page 21]
-
-INTERNET-DRAFT                                                 Feb. 2004
-
-
-Authors' Addresses
-
-   Yuji Kamite
-   NTT Communications Corporation
-   Tokyo Opera City Tower
-   3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
-   163-1421, Japan
-   EMail: y.kamite@ntt.com
-
-
-   Masaya Nakayama
-   Information Technology Center, The University of Tokyo
-   2-11-16 Yayoi, Bunkyo-ku, Tokyo
-   113-8658, Japan
-   EMail: nakayama@nc.u-tokyo.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.                                                [Page 22]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
deleted file mode 100644
index 1133b0c87d49..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
+++ /dev/null
@@ -1,466 +0,0 @@
-
-
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-UPDATES RFC 2845                                   Motorola Laboratories
-Expires: February 2005                                       August 2004
-
-
-                  HMAC SHA TSIG Algorithm Identifiers
-                  ---- --- ---- --------- -----------
-                  <draft-ietf-dnsext-tsig-sha-00.txt>
-
-
-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,
-   or will be disclosed, and any of which I become aware will be
-   disclosed, in accordance with RFC 3668.
-
-   This draft is intended to be become a Proposed Standard RFC.
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   Use of the TSIG DNS resource record requires specification of a
-   cryptographic message authentication code.  Currently identifiers
-   have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
-   This document standardizes identifiers for additional HMAC SHA TSIG
-   algorithms and standardizes how to specify the truncation of HMAC
-   values.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2004. All Rights Reserved.
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright Notice...........................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-
-      2. Algorithms and Identifiers..............................4
-
-      3. Specifying Truncation...................................5
-
-      4. IANA Considerations.....................................6
-      5. Security Considerations.................................6
-      6. Copyright and Disclaimer................................6
-
-      7. Normative References....................................7
-      8. Informative References..................................7
-
-      Authors Address............................................8
-      Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-1. Introduction
-
-   [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
-   authenticate DNS queries and responses. This RR contains a domain
-   name syntax data item which names the authentication algorithm used.
-   [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for
-   authentication codes using the HMAC [RFC 2104] algorithm with the MD5
-   [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an
-   identifier for TSIG authentication where the cryptographic operations
-   are delegated to GSS [RFC 3645].
-
-   In section 2, this document specifies additional names for TSIG
-   authentication algorithms based on US NIST SHA algorithms and HMAC.
-
-   In section 3, this document specifies the meaning of inequality
-   between the normal output size of the specified hash function and the
-   length of MAC (message authentication code) data given in the TSIG
-   RR. In particular, it specifies that a shorter length field value
-   specifies truncation and a longer length field is an error.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-2. Algorithms and Identifiers
-
-   TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
-   queries and responses.  They are intended to be efficient symmetric
-   authentication codes based on a shared secret. (Asymmetric signatures
-   can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
-   can be used for transaction signatures.) Used with a strong hash
-   function, HMAC [RFC 2104] provides a way to calculate such symmetric
-   authentication codes. The only specified HMAC based TSIG algorithm
-   identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
-
-   The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as
-   compared with the 128 bits for MD5, and additional hash algorithms in
-   the SHA family [FIPS 180-2, RFC sha224] with 224, 256, 384, and 512
-   bits, may be preferred in some case. Use of TSIG between a DNS
-   resolver and server is by mutual agreement. That agreement can
-   include the support of additional algorithms.
-
-   For completeness in relation to HMAC based algorithms, the current
-   HMAC-MD5.SIG-ALG.REG.INT identifier is included in the table below.
-   Implementations which support TSIG MUST implement HMAC MD5, SHOULD
-   implement HMAC SHA-1, and MAY implement gss-tsig and the other
-   algorithms listed below.
-
-         Mandatory      HMAC-MD5.SIG-ALG.REG.INT
-         Recommended    hmac-sha1
-         Optional       hmac-sha224
-         Optional       hmac-sha256
-         Optional       hamc-sha384
-         Optional       hmac-sha512
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
-   In some cases, it is reasonable to truncate the output of HMAC and
-   use the truncated value for authentication. HMAC SHA-1 truncated to
-   96 bits is an optional available in several IETF protocols including
-   IPSEC and TLS.
-
-   The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
-   size of the MAC field in octets. But [RFC 2845] does not specify what
-   to do if this MAC size differs from the length of the output of HMAC
-   for a particular hash function.
-
-   The specification for TSIG handling is changed as follows:
-
-   1. If The "MAC size" field is larger than the HMAC output length or
-      is zero: This case MUST NOT be generated and if received MUST
-      cause the packet to be dropped and RCODE 1 (FORMERR) to be
-      returned.
-
-   2. If the "MAC size" field equals the HMAC output length: Operation
-      is as described in [RFC 2845].
-
-   3. If the "MAC size" field is less than the HMAC output length but is
-      not zero: This is sent when the signer has truncated the HMAC
-      output as described in RFC 2104, taking initial octets and
-      discarding trailing octets. TSIG truncation can only be to an
-      integral number of octets. On receipt of a packet with truncation
-      thus indicated, the locally calculated MAC is similarly truncated
-      and only the truncated values compared for authentication.
-
-   TSIG implementations SHOULD implement SHA-1 truncated to 96 bits (12
-   octets) and MAY implement any or all other truncations valid under
-   case 3 above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-4. IANA Considerations
-
-   This document, on approval for publication as a standards track RFC,
-   registers the new TSIG algorithm identifiers listed in Section 2 with
-   IANA.
-
-
-
-5. Security Considerations
-
-   For all of the message authentication code algorithms listed herein,
-   those producing longer values are believed to be stronger; however,
-   while there are some arguments that mild truncation can strengthen a
-   MAC by reducing the information available to an attacker, excessive
-   truncation clearly weakens authentication by reducing the number of
-   bits an attacker has to try to force. See [RFC 2104] which recommends
-   that ah HMAC never be truncated to less than half its length nor to
-   less than 80 bits (10 octets).
-
-   See also the Security Considerations section of [RFC 2845].
-
-
-
-6. 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-7. Normative References
-
-   [FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal
-   Information Processing Standard, Draft, 1 August 2002.
-
-   [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
-   1321, April 1992.
-
-   [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-   Hashing for Message Authentication", RFC 2104, February 1997.
-
-   [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
-   IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
-   RFC 2845, May 2000.
-
-   [RFC sha224] - "A 224-bit One-way Hash Function: SHA-224", R.
-   Housley, December 2003, work in progress, draft-ietf-pkix-
-   sha224-*.txt.
-
-
-
-8. Informative References.
-
-   [FIPS 180-1] - Secure Hash Standard, (SHA-1) US Federal Information
-   Processing Standard, 17 April 1995.
-
-   [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
-   Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
-   1 (SHA1)", RFC 3174, September 2001.
-
-   [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
-   J., and R. Hall, "Generic Security Service Algorithm for Secret Key
-   Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
-   2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-Authors 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 in February 2005.
-
-   Its file name is draft-ietf-dnsext-tsig-sha-00.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt
deleted file mode 100644
index d65fa7104251..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt
+++ /dev/null
@@ -1,1010 +0,0 @@
-
-
-
-
-
-
-dnsext Working Group                                           B. Halley
-Internet Draft                                                   Nominum
-Expiration Date: March 2004
-                                                                E. Lewis
-                                                                    ARIN
-
-                                                          September 2003
-
-
-                Clarifying the Role of Wild Card Domains
-                       in the Domain Name System
-
-
-                 draft-ietf-dnsext-wcard-clarify-02.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   To view the list Internet-Draft Shadow Directories, see
-   http://www.ietf.org/shadow.html.
-
-Abstract
-
-   The definition of wild cards is recast from the original in RFC 1034,
-   in words that are more specific and in line with RFC 2119.  This
-   document is meant to supplement the definition in RFC 1034 and to
-   alter neither the spirit nor intent of that definition.
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 1]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-Table of Contents
-
-          Abstract  ................................................   1
-    1     Introduction  ............................................   2
-    1.1   Document Limits  .........................................   3
-    1.2   Existence  ...............................................   4
-    1.3   An Example  ..............................................   4
-    1.4   Empty Non-terminals  .....................................   5
-    1.5   Terminology  .............................................   6
-    2     Defining the Wild Card Domain Name  ......................   7
-    3     Defining Existence  ......................................   8
-    4     Impact of a Wild Card In a Query or in RDATA  ............   8
-    5     Impact of a Wild Card Domain On a Response  ..............   9
-    6     Considerations with Special Types  .......................  12
-    6.1   SOA RR's at a Wild Card Domain Name  .....................  12
-    6.2   NS RR's at a Wild Card Domain Name  ......................  12
-    6.3   CNAME RR's at a Wild Card Domain Name  ...................  13
-    6.4   DNAME RR's at a Wild Card Domain Name  ...................  13
-    7     Security Considerations  .................................  14
-    8     References  ..............................................  14
-    9     Others Contributing to This Document  ....................  14
-   10     Editors  .................................................  15
-          Appendix A: Subdomains of Wild Card Domain Names  ........  16
-          Full Copyright Statement  ................................  18
-          Acknowledgement  .........................................  18
-
-
-
-
-1. Introduction
-
-   The first section of this document will give a crisp overview of what
-   is begin defined, as well as the motivation rewording of an original
-   document and making a change to bring the specification in line with
-   implementations.  Examples are included to help orient the reader.
-
-   Wild card domain names are defined in Section 4.3.3. of RFC 1034 as
-   "instructions for synthesizing RRs." [RFC1034].  The meaning of this
-   is that a specific, special domain name is used to construct
-   responses in instances in which the query name is not otherwise
-   represented in a zone.
-
-   A wild card domain name has a specific range of influence on query
-   names (QNAMEs) within a given class, which is rooted at the domain
-   name containing the wild card label, and is limited by explicit
-   entries, zone cuts and empty non-terminal domains (see section 1.3 of
-   this document).
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 2]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   Note that a wild card domain name has no special impact on the search
-   for a query type (QTYPE).  If a domain name is found that matches the
-   QNAME (exact or a wild card) but the QTYPE is not found at that
-   point, the proper response is that there is no data available.  The
-   search does not continue on to seek other wild cards that might match
-   the QTYPE.  To illustrate, a wild card owning an MX RR does not
-   'cover' other names in the zone that own an A RR.  There are certain
-   special case RR types that will be singled out for discussion, the
-   SOA RR, NS RR, CNAME RR, and DNAME RR.
-
-   Why is this document needed?  Empirical evidence suggests that the
-   words in RFC 1034 are not clear enough.  There exist a number of
-   implementations that have strayed (each differently) from that
-   definition.  There also exists a misconception of operators that the
-   wild card can be used to add a specific RR type to all names, such as
-   the MX RR example cited above.  This document is also needed as input
-   to efforts to extend DNS, such as the DNS Security Extensions [RFC
-   2535].  Lack of a clear base specification has proven to result in
-   extension documents that have unpredictable consequences.  (This is
-   true in general, not just for DNS.)
-
-   Another reason this clarification is needed is to answer questions
-   regarding authenticated denial of existence, a service introduced in
-   the DNS Security Extensions [RFC 2535].  Prior to the work leading up
-   to this document, it had been feared that a large number of proof
-   records (NXTs) might be needed in each reply because of the unknown
-   number of potential wild card domains that were thought to be
-   applicable.  One outcome of this fear is a now discontinued document
-   solving a problem that is now known not to exist.  I.e., this
-   clarification has the impact of defending against unwarranted
-   protocol surgery.  It is not "yet another" effort to just rewrite the
-   early specifications for the sake of purity.
-
-   Although the effort to define the DNS Security Extensions has
-   prompted this document, the clarifications herein relate to basic DNS
-   only.  No DNS Security Extensions considerations are mentioned in the
-   document.
-
-1.1. Document Limits
-
-   This document limits itself to reinforcing the concepts in RFC 1034.
-   In the effort to do this, a few issues have been discussed that
-   change parts of what is in RFC 1034.  The discussions have been held
-   within the DNS Extensions Working Group.
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 3]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   Briefly, the issues raised include:
-     - The lack of clarity in the definition of domain name existence
-     - Implications of a wild card domain name owning any of the
-       following resource record sets: DNAME [RFC 2672], CNAME, NS, and
-       SOA
-     - Whether RFC 1034 meant to allow special processing of CNAME RR's
-       owned by wild card domain names
-
-1.2. Existence
-
-   The notion that a domain name 'exists' will arise numerous times in
-   this discussion.  RFC 1034 raises the issue of existence in a number
-   of places, usually in reference to non-existence and often in
-   reference to processing involving wild card domain names.  RFC 1034
-   contains algorithms that describe how domain names impact the
-   preparation of an answer and does define wild cards as a means of
-   synthesizing answers.  Because of this a discussion on wild card
-   domain names has to start with the issue of existence.
-
-   To help clarify the topic of wild cards, a positive definition of
-   existence is needed.  Complicating matters, though, is the
-   realization that existence is relative.  To an authoritative server,
-   a domain name exists if the domain name plays a role following the
-   algorithms of preparing a response.  To a resolver, a domain name
-   exists if there is any data available corresponding to the name.  The
-   difference between the two is the synthesis of records according to a
-   wild card.
-
-   For the purposes of this document, the point of view of an
-   authoritative server is adopted.  A domain name is said to exist if
-   it plays a role in the execution of the algorithms in RFC 1034.
-
-1.3. An Example
-
-   For example, consider this wild card domain name: *.example.  Any
-   query name under example. is a candidate to be matched (answered) by
-   this wild card, i.e., to have an response returned that is
-   synthesized from the wild card's RR sets.  Although any name is a
-   candidate, not all queries will match.
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 4]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   To further illustrate this, consider this zone:
-
-             $ORIGIN example.
-             @                IN  SOA
-                                  NS
-                                  NS
-             *                    TXT "this is a wild card"
-                                  MX  10 mailhost.example.
-             host1                A   10.0.0.1
-             _ssh._tcp.host1      SRV
-             _ssh._tcp.host2      SRV
-             subdel               NS
-
-
-   The following queries would be synthesized from the wild card:
-
-        QNAME=host3.example. QTYPE=MX, QCLASS=IN
-             the answer will be a "host3.example. IN MX ..."
-        QNAME=host3.example. QTYPE=A, QCLASS=IN
-             the answer will reflect "no error, but no data"
-             because there is no A RR set at '*'
-
-   The following queries would not be synthesized from the wild card:
-
-        QNAME=host1.example., QTYPE=MX, QCLASS=IN
-             because host1.example. exists
-        QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
-             because _tcp.host1.example. exists (without data)
-        QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
-             because host2.example. exists (without data)
-        QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
-             because subdel.example. exists and is a zone cut
-
-   To the server, the following domains are considered to exist in the
-   zone: *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2,
-   _ssh._tcp.host2, and subdel.  To a resolver, many more domains appear
-   to exist via the synthesis of the wild card.
-
-1.4. Empty Non-terminals
-
-   Empty non-terminals are domain names that own no data but have
-   subdomains.  This is defined in section 3.1 of RFC 1034:
-
-#    The domain name space is a tree structure.  Each node and leaf on the
-#    tree corresponds to a resource set (which may be empty).  The domain
-#    system makes no distinctions between the uses of the interior nodes and
-#    leaves, and this memo uses the term "node" to refer to both.
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 5]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   The parenthesized "which may be empty" specifies that empty non-
-   terminals are explicitly recognized.  According to the definition of
-   existence in this document, empty non-terminals do exist at the
-   server.
-
-   Carefully reading the above paragraph can lead to an interpretation
-   that all possible domains exist - up to the suggested limit of 255
-   octets for a domain name [RFC 1035].  For example, www.example. may
-   have an A RR, and as far as is practically concerned, is a leaf of
-   the domain tree.  But the definition can be taken to mean that
-   sub.www.example. also exists, albeit with no data.  By extension, all
-   possible domains exist, from the root on down.  As RFC 1034 also
-   defines "an authoritative name error indicating that the name does
-   not exist" in section 4.3.1, this is not the intent of the original
-   document.
-
-   RFC1034's wording is to be clarified by adding the following
-   paragraph:
-
-        A node is considered to have an impact on the algorithms of
-        4.3.2 if it is a leaf node with any resource sets or an interior
-        node, with or without a resource set, that has a subdomain that
-        is a leaf node with a resource set.  A QNAME and QCLASS matching
-        an existing node never results in a response return code of
-        authoritative name error.
-
-   The terminology in the above paragraph is chosen to remain as close
-   to that in the original document.  The term "with" is a alternate
-   form for "owning" in this case, hence "a leaf node owning resources
-   sets, or an interior node, owning or not owning any resource set,
-   that has a leaf node owning a resource set as a subdomain," is the
-   proper interpretation of the middle sentence.
-
-   As an aside, an "authoritative name error" has been called NXDOMAIN
-   in some RFCs, such as RFC 2136 [RFC 2136].  NXDOMAIN is the mnemonic
-   assigned to such an error by at least one implementation of DNS.  As
-   this mnemonic is specific to implementations, it is avoided in the
-   remainder of this document.
-
-1.5. 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 the document entitled
-   "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119]
-
-   Requirements are denoted by paragraphs that begin with with the
-   following convention: 'R'<sect>.<count>.
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 6]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   Quotations of RFC 1034 (as has already been done once above) are
-   denoted by a '#' in the leftmost column.
-
-2. Defining the Wild Card Domain Name
-
-   A wild card domain name is defined by having the initial label be:
-
-        0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
-   This defines domain names that may play a role in being a wild card,
-   that is, being a source for synthesized answers.  Domain names
-   conforming to this definition that appear in queries and RDATA
-   sections do not have any special role.  These cases will be described
-   in more detail in following sections.
-
-   R2.1 A domain name that is to be interpreted as a wild card MUST
-        begin with a label of '0000 0001 0010 1010' in binary.
-
-   The first octet is the normal label type and length for a 1 octet
-   long label, the second octet is the ASCII representation [RFC 20] for
-   the '*' character.  In RFC 1034, ASCII encoding is assumed to be the
-   character encoding.
-
-   In the master file formats used in RFCs, a "*" is a legal
-   representation for the wild card label.  Even if the "*" is escaped,
-   it is still interpreted as the wild card when it is the only
-   character in the label.
-
-   R2.2 A server MUST treat a wild card domain name as the basis of
-        synthesized answers regardless of any "escape" sequences in the
-        input format.
-
-   RFC 1034 and RFC 1035 ignore the case in which a domain name might be
-   "the*.example.com." The interpretation is that this domain name in a
-   zone would only match queries for "the*.example.com" and not have any
-   other role.
-
-   Note: By virtue of this definition, a wild card domain name may have
-   a subdomain.  The subdomain (or sub-subdomain) itself may also be a
-   wild card.  E.g., *.*.example. is a wild card, so is *.sub.*.example.
-   More discussion on this is given in Appendix A.
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 7]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-3. Defining Existence
-
-   As described in the Introduction, a precise definition of existence
-   is needed.
-
-   R3.1 An authoritative server MUST treat a domain name as existing
-        during the execution of the algorithms in RFC 1034 when the
-        domain name conforms to the following definition.  A domain name
-        is defined to exist if the domain name owns data and/or has a
-        subdomain that exists.
-
-   Note that at a zone boundary, the domain name owns data, including
-   the NS RR set.  At the delegating server, the NS RR set is not
-   authoritative, but that is of no consequence here.  The domain name
-   owns data, therefore, it exists.
-
-   R3.2 An authoritative server MUST treat a domain name that has
-        neither a resource record set nor an existing subdomain as non-
-        existent when executing the algorithm in section 4.3.2. of RFC
-        1034.
-
-   A note on terminology.  A domain transcends zones, i.e., all DNS data
-   is in the root domain but segmented into zones of control.  In this
-   document, there are references to a "domain name" in the context of
-   existing "in a zone." In this usage, a domain name is the root of a
-   domain, not the entire domain.  The domain's root point is said to
-   "exist in a zone" if the zone is authoritative for the name.  RR sets
-   existing in a domain need not be owned by the domain's root domain
-   name, but are owned by other domain names in the domain.
-
-4. Impact of a Wild Card In a Query or in RDATA
-
-   When a wild card domain name appears in a question, e.g., the query
-   name is "*.example.", the response in no way differs from any other
-   query.  In other words, the wild card label in a QNAME has no special
-   meaning, and query processing will proceed using '*' as a literal
-   query name.
-
-   R4.1 A wild card domain name acting as a QNAME MUST be treated as any
-        other QNAME, there MUST be no special processing accorded it.
-
-   If a wild card domain name appears in the RDATA of a CNAME RR or any
-   other RR that has a domain name in it, the same rule applies.  In the
-   instance of a CNAME RR, the wild card domain name is used in the same
-   manner of as being the original QNAME.  For other RR's, rules vary
-   regarding what is done with the domain name(s) appearing in them, in
-   no case does the wild card hold special meaning.
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 8]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   R4.2 A wild card domain name appearing in any RR's RDATA MUST be
-        treated as any other domain name in that situation, there MUST
-        be no special processing accorded it.
-
-5. Impact of a Wild Card Domain On a Response
-
-   The description of how wild cards impact response generation is in
-   RFC 1034, section 4.3.2.  That passage contains the algorithm
-   followed by a server in constructing a response.  Within that
-   algorithm, step 3, part 'c' defines the behavior of the wild card.
-   The algorithm is directly quoted in lines that begin with a '#' sign.
-   Commentary is interleaved.
-
-   There is a documentation issue deserving some explanation.  The
-   algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo
-   code, i.e., it's steps are not intended to be followed in strict
-   order.  The "algorithm" is a suggestion.  As such, in step 3, parts
-   a, b, and c, do not have to be implemented in that order.
-
-   Another issue needing explanation is that RFC 1034 is a full
-   standard.  There is another RFC, RFC 2672, which makes, or proposes
-   an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME
-   RR.  RFC 2672 is a proposed standard.  The dilemma in writing these
-   clarifications is knowing which document is the one being clarified.
-   Fortunately, the difference between RFC 1034 and RFC 2672 is not
-   significant with respect to wild card synthesis, so this document
-   will continue to state that it is clarifying RFC 1034.  If RFC 2672
-   progresses along the standards track, it will need to refer to
-   modifying RFC 1034's algorithm as amended here.
-
-   The context of part 'c' is that the search is progressing label by
-   label through the QNAME.  (Note that the data being searched is the
-   authoritative data in the server, the cache is searched in step 4.)
-   Step 3's part 'a' covers the case that the QNAME has been matched in
-   full, regardless of the presence of a CNAME RR.  Step 'b' covers
-   crossing a cut point, resulting in a referral.  All that is left is
-   to look for the wild card.
-
-   Step 3 of the algorithm also assumes that the search is looking in
-   the zone closest to the answer, i.e., in the same class as QCLASS and
-   as close to the authority as possible on this server.  If the zone is
-   not the authority, then a referral is given, possibly one indicating
-   lameness.
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                  [Page 9]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-#         c. If at some label, a match is impossible (i.e., the
-#            corresponding label does not exist), look to see if a
-#            the "*" label exists.
-
-   The above paragraph refers to finding the domain name that exists in
-   the zone and that most encloses the QNAME.  Such a domain name will
-   mark the boundary of candidate wild card domain names that might be
-   used to synthesize an answer.  (Remember that at this point, if the
-   most enclosing name is the same as the QNAME, part 'a' would have
-   recorded an exact match.)  The existence of the enclosing name means
-   that no wild card name higher in the tree is a candidate to answer
-   the query.
-
-   Once the closest enclosing node is identified, there's the matter of
-   what exists below it.  It may have subdomains, but none will be
-   closer to the QNAME.  One of the subdomains just might be a wild
-   card.  If it exists, this is the only wild card eligible to be used
-   to synthesize an answer for the query.  Even if the closest enclosing
-   node conforms to the syntax rule in section 2 for being a wild card
-   domain name, the closest enclosing node is not eligible to be a
-   source of a synthesized answer.
-
-   The only wild card domain name that is a candidate to synthesize an
-   answer will be the "*" subdomain of the closest enclosing domain
-   name.  Three possibilities can happen.  The "*" subdomain does not
-   exist, the "*" subdomain does but does not have an RR set of the same
-   type as the QTYPE, or it exists and has the desired RR set.
-
-   For the sake of brevity, the closest enclosing node can be referred
-   to as the "closest encloser." The closest encloser is the most
-   important concept in this clarification.  Describing the closest
-   encloser is a bit tricky, but it is an easy concept.
-
-   To find the closest encloser, you have to first locate the zone that
-   is the authority for the query name.  This eliminates the need to be
-   concerned that the closest encloser is a cut point.  In addition, we
-   can assume too that the query name does not exist, hence the closest
-   encloser is not equal to the query name.  We can assume away these
-   two cases because they are handled in steps 2, 3a and 3b of section
-   4.3.2.'s algorithm.
-
-   What is left is to identify the existing domain name that would have
-   been up the tree (closer to the root) from the query name.  Knowing
-   that an exact match is impossible, if there is a "*" label descending
-   from the unique closest encloser, this is the one and only wild card
-   from which an answer can be synthesized for the query.
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 10]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   To illustrate, using the example in section 1.2 of this document, the
-   following chart shows QNAMEs and the closest enclosers.  In
-   Appendix A there is another chart showing unusual cases.
-
-        QNAME                        Closest Encloser     Wild Card Source
-        host3.example.               example.             *.example.
-        _telnet._tcp.host1.example.  _tcp.host1.example.  no wild card
-        _telnet._tcp.host2.example.  host2.example.       no wild card
-        _telnet._tcp.host3.example.  example.             *.example.
-        _chat._udp.host3.example.    example.             *.example.
-
-   Note that host1.subdel.example. is in a subzone, so the search for it
-   ends in a referral in part 'b', thus does not enter into finding a
-   closest encloser.
-
-   The fact that a closest encloser will be the only superdomain that
-   can have a candidate wild card will have an impact when it comes to
-   designing authenticated denial of existence proofs.
-
-#            If the "*" label does not exist, check whether the name
-#            we are looking for is the original QNAME in the query
-#            or a name we have followed due to a CNAME.  If the name
-#            is original, set an authoritative name error in the
-#            response and exit.  Otherwise just exit.
-
-   The above passage says that if there is not even a wild card domain
-   name to match at this point (failing to find an explicit answer
-   elsewhere), we are to return an authoritative name error at this
-   point.  If we were following a CNAME, the specification is unclear,
-   but seems to imply that a no error return code is appropriate, with
-   just the CNAME RR (or sequence of CNAME RRs) in the answer section.
-
-#            If the "*" label does exist, match RRs at that node
-#            against QTYPE.  If any match, copy them into the answer
-#            section, but set the owner of the RR to be QNAME, and
-#            not the node with the "*" label.  Go to step 6.
-
-   This final paragraph covers the role of the QTYPE in the process.
-   Note that if no resource record set matches the QTYPE the result is
-   that no data is copied, but the search still ceases ("Go to step
-   6.").  In the following section, a suggested change is made to this,
-   under the heading "CNAME RRs at a Wild Card Domain Name."
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 11]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-6. Considerations with Special Types
-
-   For the purposes of this section, "special" means that a record
-   induces processing at the server beyond simple lookup.  The special
-   types in this section are SOA, NS, CNAME, and DNAME.  SOA is special
-   because it is used as a zone marker and has an impact on step 2 of
-   the algorithm in 4.3.2.  NS denotes a cut point and has an impact on
-   step 3b.  CNAME redirects the query and is mentioned in steps 3a and
-   3b.  DNAME is a "CNAME generator."
-
-6.1. SOA RR's at a Wild Card Domain Name
-
-   If the owner of an SOA record conforms to the basic rules of owning
-   an SOA RR (meaning it is the apex of a zone) the impact on the search
-   algorithm is not in section 3c (where records are synthesized) as
-   would be expected.  The impact is really in step 2 of the algorithm,
-   the choice of zone.
-
-   We are no longer talking about whether or not an SOA RR can be
-   synthesized in a response because we are shifting attention to step
-   2.  We are now talking about what it means for a name server to
-   synthesize a zone for a response.  To date, no implementation has
-   done this.  Thinking ahead though, anyone choosing to pursue this
-   would have to be aware that a server would have to be able to
-   distinguish between queries for data it will have to synthesize and
-   queries that ought to be treated as if they were prompted by a lame
-   delegation.
-
-   It is not a protocol error to have an SOA RR owned by a wild card
-   domain name, just as it is not an error to have zone name be
-   syntactically equivalent to a domain name.  However, this situation
-   requires careful consideration of how a server chooses the
-   appropriate zone for an answer.  And an SOA RR is not able to be
-   synthesized as in step 3c.
-
-6.2. NS RR's at a Wild Card Domain Name
-
-   Complimentary to the issue of an SOA RR owned by a wild card domain
-   name is the issue of NS RR's owned by a wild card domain name.  In
-   this instance, each machine being referred to in the RDATA of the NS
-   RR has to be able to understand the impact of this on step 2, the
-   choosing of the authoritative zone.
-
-   Referring to the same machine in such a NS RR will probably not work
-   well.  This is because the server may become confused as to whether
-   the query name ought to be answered by the zone owning the NS RR in
-   question or a synthesized zone.  (It isn't known in advance that the
-   query name will invoke the wild card synthesis.)
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 12]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   The status of other RR's owned by a wild card domain name is the same
-   as if the owner name was not a wild card domain name.  I.e., when
-   there is a NS RR at a wild card domain name, other records are
-   treated as being below the zone cut.
-
-   Is it not a protocol error to have a NS RR owned by a wild card
-   domian name, complimentary to the case of a SOA RR.  However, for
-   this to work, an implementation has to know how to synthesize a zone.
-
-6.3. CNAME RR's at a Wild Card Domain Name
-
-   The issue of CNAME RR's owned by wild card domain names has prompted
-   a suggested change to the last paragraph of step 3c of the algorithm
-   in 4.3.2.  The changed text is this:
-
-        If the "*" label does exist and if the data at the node is a
-        CNAME and QTYPE doesn't match CNAME, copy the CNAME RR into the
-        answer section of the response, set the owner of the CNAME RR to
-        be QNAME, and then change QNAME to the canonical name in the
-        CNAME RR, and go back to step 1.
-
-        If the "*" label does exist and either QTYPE is CNAME or the
-        data at the node is not a CNAME, then match RRs at that node
-        against QTYPE.  If any match, copy them into the answer section,
-        but set the owner of the RR to be QNAME, and not the node with
-        the "*" label.  Go to step 6.
-
-   Apologies if the above isn't clear, but an attempt was made to stitch
-   together the passage using just the phrases in section 3a and 3c of
-   the algorithm so as to preserve the original flavor.
-
-   In case the passage as suggested isn't clear enough, the intent is to
-   make "landing" at a wild card name and finding a CNAME the same as if
-   this happened as a result of a direct match.  I.e., Finding a CNAME
-   at the name matched in step 3c is supposed to have the same impact as
-   finding the CNAME in step 3a.
-
-6.4. DNAME RR's at a Wild Card Domain Name
-
-   The specification of the DNAME RR, which is at the proposed level of
-   standardization, is not as mature as the full standard in RFC 1034.
-   Because of this, or the reason for this is, there appears to be a
-   host of issues with that definition and it's rewrite of the algorithm
-   in 4.3.2.  For the time being, when it comes to wild card processing
-   issues, a DNAME can be considered to be a CNAME synthesizer.  A DNAME
-   at a wild card domain name is effectively the same as a CNAME at a
-   wild card domain name.
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 13]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-7. Security Considerations
-
-   This document is refining the specifications to make it more likely
-   that security can be added to DNS.  No functional additions are being
-   made, just refining what is considered proper to allow the DNS,
-   security of the DNS, and extending the DNS to be more predictable.
-
-8. References
-
-   Normative References
-
-   [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
-
-   [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
-               Nov-01-1987
-
-   [RFC 1035] Domain Names - Implementation and Specification, P.V
-               Mockapetris, Nov-01-1987
-
-   [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
-               Bradner, March 1997
-
-   Informative References
-
-   [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie,
-               Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
-
-   [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999
-
-   [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999
-
-9. Others Contributing to This Document
-
-   Others who have directly caused text to appear in the document: Paul
-   Vixie and Olaf Kolkman.  Many others have indirect influences on the
-   content.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 14]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-10. Editors
-
-        Name:         Bob Halley
-        Affiliation:  Nominum, Inc.
-        Address:      2385 Bay Road, Redwood City, CA 94063 USA
-        Phone:        +1-650-381-6016
-        EMail:        Bob.Halley@nominum.com
-
-        Name:         Edward Lewis
-        Affiliation:  ARIN
-        Address:      3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA
-        Phone:        +1-703-227-9854
-        Email:        edlewis@arin.net
-
-   Comments on this document can be sent to the editors or the mailing
-   list for the DNSEXT WG, namedroppers@ops.ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 15]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-Appendix A: Subdomains of Wild Card Domain Names
-
-   In reading the definition of section 2 carefully, it is possible to
-   rationalize unusual names as legal.  In the example given,
-   *.example. could have subdomains of *.sub.*.example. and even the
-   more direct *.*.example.  (The implication here is that these domain
-   names own explicit resource records sets.)  Although defining these
-   names is not easy to justify, it is important that implementions
-   account for the possibility.  This section will give some further
-   guidence on handling these names.
-
-   The first thing to realize is that by all definitions, subdomains of
-   wild card domain names are legal.  In analyzing them, one realizes
-   that they cause no harm by their existence.  Because of this, they
-   are allowed to exist, i.e., there are no special case rules made to
-   disallow them.  The reason for not preventing these names is that the
-   prevention would just introduce more code paths to put into
-   implementations.
-
-   The concept of "closest enclosing" existing names is important to
-   keep in mind.  It is also important to realize that a wild card
-   domain name can be a closest encloser of a query name.  For example,
-   if *.*.example. is defined in a zone, and the query name is
-   a.*.example., then the closest enclosing domain name is *.example.
-   Keep in mind that the closest encloser is not eligible to be a source
-   of synthesized answers, just the subdomain of it that has the first
-   label "*".
-
-   To illustrate this, the following chart shows some matches.  Assume
-   that the names *.example., *.*.example., and *.sub.*.example. are
-   defined in the zone.
-
-        QNAME               Closest Encloser  Wild Card Source
-        a.example.          example.          *.example.
-        b.a.example.        example.          *.example.
-        a.*.example.        *.example.        *.*.example.
-        b.a.*.example.      *.example.        *.*.example.
-        b.a.*.*.example.    *.*.example.      no wild card
-        a.sub.*.example.    sub.*.example.    *.sub.*.example.
-        b.a.sub.*.example.  sub.*.example.    *.sub.*.example.
-        a.*.sub.*.example.  *.sub.*.example.  no wild card
-        *.a.example.        example.          *.example.
-        a.sub.b.example.    example.          *.example.
-
-   Recall that the closest encloser itself cannot be the wild card.
-   Therefore the match for b.a.*.*.example. has no applicable wild card.
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 16]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003
-
-
-   Finally, if a query name is sub.*.example., any answer available will
-   come from an exact name match for sub.*.example.  No wild card
-   synthesis is performed in this case.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 17]
-
-Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Halley & Lewis            [Expires March 2004]                 [Page 18]
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt
deleted file mode 100644
index e9943015e4e9..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt
+++ /dev/null
@@ -1,1120 +0,0 @@
-
-
-DNS Operations                                                 M. Larson
-Internet-Draft                                                 P. Barber
-Expires: August 16, 2004                                        VeriSign
-                                                       February 16, 2004
-
-
-                  Observed DNS Resolution Misbehavior
-                    draft-ietf-dnsop-bad-dns-res-02
-
-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 16, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-   This Internet-Draft describes DNS name server and resolver behavior
-   that results in a significant query volume sent to the root and
-   top-level domain (TLD) name servers.  In some cases we recommend
-   minor additions to the DNS protocol specification and corresponding
-   changes in name server implementations to alleviate these unnecessary
-   queries. The recommendations made in this document are a direct
-   byproduct of observation and analysis of abnormal query traffic
-   patterns seen at two of the thirteen root name servers and all
-   thirteen com/net TLD name servers.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 1]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   document are to be interpreted as described in RFC 2119 [1].
-
-Table of Contents
-
-   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.     Observed name server misbehavior . . . . . . . . . . . . .   4
-   2.1    Aggressive requerying for delegation information . . . . .   4
-   2.1.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .   5
-   2.2    Repeated queries to lame servers . . . . . . . . . . . . .   5
-   2.2.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .   6
-   2.3    Inability to follow multiple levels of out-of-zone glue  .   6
-   2.3.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .   7
-   2.4    Aggressive retransmission when fetching glue . . . . . . .   7
-   2.4.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .   8
-   2.5    Aggressive retransmission behind firewalls . . . . . . . .   8
-   2.5.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .   8
-   2.6    Misconfigured NS records . . . . . . . . . . . . . . . . .   9
-   2.6.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .  10
-   2.7    Name server records with zero TTL  . . . . . . . . . . . .  10
-   2.7.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .  11
-   2.8    Unnecessary dynamic update messages  . . . . . . . . . . .  11
-   2.8.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .  11
-   2.9    Queries for domain names resembling IP addresses . . . . .  12
-   2.9.1  Recommendation . . . . . . . . . . . . . . . . . . . . . .  12
-   2.10   Misdirected recursive queries  . . . . . . . . . . . . . .  12
-   2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . . . .  13
-   2.11   Suboptimal name server selection algorithm . . . . . . . .  13
-   2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . . . .  13
-   3.     IANA considerations  . . . . . . . . . . . . . . . . . . .  15
-   4.     Security considerations  . . . . . . . . . . . . . . . . .  16
-   5.     Internationalization considerations  . . . . . . . . . . .  17
-          Normative References . . . . . . . . . . . . . . . . . . .  18
-          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  18
-          Intellectual Property and Copyright Statements . . . . . .  19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 2]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-1. Introduction
-
-   Observation of query traffic received by two root name servers and
-   the thirteen com/net TLD name servers has revealed that a large
-   proportion of the total traffic often consists of "requeries".  A
-   requery is the same question (<qname, qtype, qclass>) asked
-   repeatedly at an unexpectedly high rate.  We have observed requeries
-   from both a single IP address and multiple IP addresses.
-
-   By analyzing requery events we have found that the cause of the
-   duplicate traffic is almost always a deficient name server, stub
-   resolver and/or application implementation combined with an
-   operational anomaly.  The implementation deficiencies we have
-   identified to date include well-intentioned recovery attempts gone
-   awry, insufficient caching of failures, early abort when multiple
-   levels of glue records must be followed, and aggressive retry by stub
-   resolvers and/or applications.  Anomalies that we have seen trigger
-   requery events include lame delegations, unusual glue records, and
-   anything that makes all authoritative name servers for a zone
-   unreachable (DoS attacks, crashes, maintenance, routing failures,
-   congestion, etc.).
-
-   In the following sections, we provide a detailed explanation of the
-   observed behavior and recommend changes that will reduce the requery
-   rate.  Some of the changes recommended affect the core DNS protocol
-   specification, described principally in RFC 1034 [2], RFC 1035 [3]
-   and RFC 2181 [4].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 3]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-2. Observed name server misbehavior
-
-2.1 Aggressive requerying for delegation information
-
-   There can be times when every name server in a zone's NS RRset is
-   unreachable (e.g., during a network outage), unavailable (e.g., the
-   name server process is not running on the server host) or
-   misconfigured (e.g., the name server is not authoritative for the
-   given zone, also known as "lame").  Consider a recursive name server
-   that attempts to resolve a query for a domain name in such a zone and
-   discovers that none of the zone's name servers can provide an answer.
-   We have observed a recursive name server implementation that then
-   verifies the zone's NS RRset in its cache by querying for the zone's
-   delegation information: it sends a query for the zone's NS RRset to
-   one of the parent zone's name servers.
-
-   For example, suppose that "example.com" has the following NS RRset:
-
-     example.com.   IN   NS   ns1.example.com.
-     example.com.   IN   NS   ns2.example.com.
-
-   Upon receipt of a query for "www.example.com" and assuming that
-   neither "ns1.example.com" nor "ns2.example.com" can provide an
-   answer, this recursive name server implementation immediately queries
-   a "com" zone name server for the "example.com" NS RRset to verify it
-   has the proper delegation information.  This name server
-   implementation performs this query to a zone's parent zone for each
-   recursive query it receives that fails because of a completely
-   unresponsive set of name servers for the target zone.  Consider the
-   effect when a popular zone experiences a catastrophic failure of all
-   its name servers: now every recursive query for domain names in that
-   zone sent to this name server implementation results in a query to
-   the failed zone's parent name servers.  On one occasion when several
-   dozen popular zones became unreachable, the query load on the com/net
-   name servers increased by 50%.
-
-   We believe this verification query is not reasonable.  Consider the
-   circumstances: When a recursive name server is resolving a query for
-   a domain name in a zone it has not previously searched, it uses the
-   list of name servers in the referral from the target zone's parent.
-   If on its first attempt to search the target zone, none of the name
-   servers in the referral is reachable, a verification query to the
-   parent is pointless: this query to the parent would come so quickly
-   on the heels of the referral that it would be almost certain to
-   contain the same list of name servers.  The chance of discovering any
-   new information is slim.
-
-   The other possibility is that the recursive name server successfully
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 4]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   contacts one of the target zone's name servers and then caches the NS
-   RRset from the authority section of a response, the proper behavior
-   according to section 5.4.1 of RFC 2181 [4], because the NS RRset from
-   the target zone is more trustworthy than delegation information from
-   the parent zone.  If, while processing a subsequent recursive query,
-   the recursing name server discovers that none of the name servers
-   specified in the cached NS RRset is available or authoritative,
-   querying the parent would be wrong.  An NS RRset from the parent zone
-   would now be less trustworthy than data already in the cache.
-
-   For this query of the parent zone to be useful, the target zone's
-   entire set of name servers would have to change AND the former set of
-   name servers would have to be deconfigured and/or decommissioned AND
-   the delegation information in the parent zone would have to be
-   updated with the new set of name servers, all within the TTL of the
-   target zone's NS RRset.  We believe this scenario is uncommon:
-   administrative best practices dictate that changes to a zone's set of
-   name servers happen gradually, with servers that are removed from the
-   NS RRset left authoritative for the zone as long as possible.  The
-   scenarios that we can envision that would benefit from the parent
-   requery behavior do not outweigh its damaging effects.
-
-2.1.1 Recommendation
-
-   Name servers offering recursion MUST NOT send a query for the NS
-   RRset of a non-responsive zone to any of the name servers for that
-   zone's parent zone.  For the purposes of this injunction, a
-   non-responsive zone is defined as a zone for which every name server
-   listed in the zone's NS RRset:
-
-   1.  is not authoritative for the zone (i.e., lame), or,
-
-   2.  returns a server failure response (RCODE=2), or,
-
-   3.  is dead or unreachable according to section 7.2 of RFC 2308 [5].
-
-
-2.2 Repeated queries to lame servers
-
-   Section 2.1 describes a catastrophic failure: when every name server
-   for a zone is unable to provide an answer for one reason or another.
-   A more common occurrence is a subset of a zone's name servers being
-   unavailable or misconfigured.  Different failure modes have different
-   expected durations.  Some symptoms indicate problems that are
-   potentially transient: various types of ICMP unreachable messages
-   because a name server process is not running or a host or network is
-   unreachable, or a complete lack of a response to a query.  Such
-   responses could be the result of a host rebooting or temporary
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 5]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   outages; these events don't necessarily require any human
-   intervention and can be reasonably expected to be temporary.
-
-   Other symptoms clearly indicate a condition requiring human
-   intervention, such as lame server: if a name server is misconfigured
-   and not authoritative for a zone delegated to it, it is reasonable to
-   assume that this condition has potential to last longer than
-   unreachability or unresponsiveness.  Consequently, repeated queries
-   to known lame servers are not useful.  In this case of a condition
-   with potential to persist for a long time, a better practice would be
-   to maintain a list of known lame servers and avoid querying them
-   repeatedly in a short interval.
-
-2.2.1 Recommendation
-
-   Recursive name servers SHOULD cache name servers that they discover
-   are not authoritative for zones delegated to them (i.e. lame
-   servers). Lame servers MUST be cached against the specific query
-   tuple <zone name, class, server IP address>.  Zone name can be
-   derived from the owner name of the NS record that was referenced to
-   query the name server that was discovered to be lame.
-   Implementations that perform lame server caching MUST refrain from
-   sending queries to known lame servers based on a time interval from
-   when the server is discovered to be lame.  A minimum interval of
-   thirty minutes is RECOMMENDED.
-
-2.3 Inability to follow multiple levels of out-of-zone glue
-
-   Some recursive name server implementations are unable to follow more
-   than one level of out-of-zone glue.  For example, consider the
-   following delegations:
-
-     foo.example.        IN   NS   ns1.example.com.
-     foo.example.        IN   NS   ns2.example.com.
-
-     example.com.        IN   NS   ns1.test.example.net.
-     example.com.        IN   NS   ns2.test.example.net.
-
-     test.example.net.   IN   NS   ns1.test.example.net.
-     test.example.net.   IN   NS   ns2.test.example.net.
-
-   A name server processing a recursive query for "www.foo.example" must
-   follow two levels of indirection, first obtaining address records for
-   "ns1.test.example.net" and/or "ns2.test.example.net" in order to
-   obtain address records for "ns1.example.com" and/or "ns2.example.com"
-   in order to query those name servers for the address records of
-   "www.foo.example".  While this situation may appear contrived, we
-   have seen multiple similar occurrences and expect more as new generic
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 6]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   top-level domains (gTLDs) become active.  We anticipate many zones in
-   the new gTLDs will use name servers in other gTLDs, increasing the
-   amount of inter-zone glue.
-
-2.3.1 Recommendation
-
-   Clearly constructing a delegation that relies on multiple levels of
-   out-of-zone glue is not a good administrative practice.  This issue
-   could be mitigated with an operational injunction in an RFC to
-   refrain from construction of such delegations.  In our opinion the
-   practice is widespread enough to merit clarifications to the DNS
-   protocol specification to permit it on a limited basis.
-
-   Name servers offering recursion SHOULD be able to handle at least
-   three levels of indirection resulting from out-of-zone glue.
-
-2.4 Aggressive retransmission when fetching glue
-
-   When an authoritative name server responds with a referral, it
-   includes NS records in the authority section of the response.
-   According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
-   server should also "put whatever addresses are available into the
-   additional section, using glue RRs if the addresses are not available
-   from authoritative data or the cache."  Some name server
-   implementations take this address inclusion a step further with a
-   feature called "glue fetching".  A name server that implements glue
-   fetching attempts to include A records for every NS record in the
-   authority section.  If necessary, the name server issues multiple
-   queries of its own to obtain any missing A records.
-
-   Problems with glue fetching can arise in the context of
-   "authoritative-only" name servers, which only serve authoritative
-   data and ignore requests for recursion.  Such a server will not
-   generate any queries of its own.  Instead it answers non-recursive
-   queries from resolvers looking for information in zones it serves.
-   With glue fetching enabled, however, an authoritative server will
-   generate queries whenever it needs to look up an unknown address
-   record to complete the additional section of a response.
-
-   We have observed situations where a glue-fetching name server can
-   send queries that reach other name servers, but apparently is
-   prevented from receiving the responses.  For example, perhaps the
-   name server is authoritative-only and therefore its administrators
-   expect it to receive only queries.  Perhaps unaware of glue fetching
-   and presuming that the name server will generate no queries, its
-   administrators place the name server behind a network device that
-   prevents it from receiving responses.  If this is the case, all
-   glue-fetching queries will go answered.
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 7]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   We have observed name server implementations that retry excessively
-   when glue-fetching queries are unanswered.  A single com/net name
-   server has received hundreds of queries per second from a single name
-   server.  Judging from the specific queries received and based on
-   additional analysis, we believe these queries result from overly
-   aggressive glue fetching.
-
-2.4.1 Recommendation
-
-   Implementers whose name servers support glue fetching should take
-   care to avoid sending queries at excessive rates.  Implementations
-   should support throttling logic to detect when queries are sent but
-   no responses are received.
-
-2.5 Aggressive retransmission behind firewalls
-
-   A common occurrence and one of the largest sources of repeated
-   queries at the com/net and root name servers appears to result from
-   resolvers behind misconfigured firewalls.  In this situation, a
-   recursive name server is apparently allowed to send queries through a
-   firewall to other name servers, but not receive the responses.  The
-   result is more queries than necessary because of retransmission, all
-   of which are useless because the responses are never received.  Just
-   as with the glue-fetching scenario described in Section 2.4, the
-   queries are sometimes sent at excessive rates.  To make matters
-   worse, sometimes the responses, sent in reply to legitimate queries,
-   trigger an alarm on the originator's intrusion detection system.  We
-   are frequently contacted by administrators responding to such alarms
-   who believe our name servers are attacking their systems.
-
-   Not only do some resolvers in this situation retransmit queries at an
-   excessive rate, but they continue to do so for days or even weeks.
-   This scenario could result from an organization with multiple
-   recursive name servers, only a subset of whose traffic is improperly
-   filtered in this manner.  Stub resolvers in the organization could be
-   configured to query multiple name servers.  Consider the case where a
-   stub resolver queries a filtered name server first.  This name server
-   sends one or more queries whose replies are filtered, so it can't
-   respond to the stub resolver, which times out.  The resolver
-   retransmits to a name server that is able to provide an answer.
-   Since resolution ultimately succeeds the underlying problem might not
-   be recognized or corrected.  A popular stub resolver has a very
-   aggressive retransmission schedule, including simultaneous queries to
-   multiple name servers, which could explain how such a situation could
-   persist without being detected.
-
-2.5.1 Recommendation
-
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 8]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   The most obvious recommendation is that administrators should take
-   care not to place recursive name servers behind a firewall that
-   prohibits queries to pass through but not the resulting replies.
-
-   Name servers should take care to avoid sending queries at excessive
-   rates.  Implementations should support throttling logic to detect
-   when queries are sent but no responses are received.
-
-2.6 Misconfigured NS records
-
-   Sometimes a zone administrator forgets to add the trailing dot on the
-   domain names in the RDATA of a zone's NS records.  Consider this
-   fragment of the zone file for "example.com":
-
-     $ORIGIN example.com.
-     example.com.      3600   IN   NS   ns1.example.com  ; Note missing
-     example.com.      3600   IN   NS   ns2.example.com  ; trailing dots
-
-   The zone's authoritative servers will parse the NS RDATA as
-   "ns1.example.com.example.com" and "ns2.example.com.example.com" and
-   return NS records with this incorrect RDATA in responses, including
-   typically the authority section of every response containing records
-   from the "example.com" zone.
-
-   Now consider a typical sequence of queries.  A recursive name server
-   attempting to resolve A records for "www.example.com" with no cached
-   information for this zone will query a "com" authoritative server.
-   The "com" server responds with a referral to the "example.com" zone,
-   consisting of NS records with valid RDATA and associated glue
-   records. (This example assumes that the "example.com" zone
-   information is correct in the "com" zone.)  The recursive name server
-   caches the NS RRset from the "com" server and follows the referral by
-   querying one of the "example.com" authoritative servers.  This server
-   responds with the "www.example.com" A record in the answer section
-   and, typically, the "example.com" NS records in the authority section
-   and, if space in the message remains, glue A records in the
-   additional section. According to Section 5.4 of RFC 2181 [4], NS
-   records in the authority section of an authoritative answer are more
-   trustworthy than NS records from the authority section of a
-   non-authoritative answer.  Thus the "example.com" NS RRset just
-   received from the "example.com" authoritative server displaces the
-   "example.com" NS RRset received moments ago from the "com"
-   authoritative server.
-
-   But the "example.com" zone contains the erroneous NS RRset as shown
-   in the example above.  Subsequent queries for names in "example.com"
-   will cause the server to attempt to use the incorrect NS records and
-   so the server will try to resolve the nonexistent names
-
-
-
-Larson & Barber         Expires August 16, 2004                 [Page 9]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   "ns1.example.com.example.com" and "ns2.example.com.example.com".  In
-   this example, since all of the zone's name servers are named in the
-   zone itself (i.e., "ns1.example.com.example.com" and
-   "ns2.example.com.example.com" both end in "example.com") and all are
-   bogus, the recursive server cannot reach any "example.com" name
-   servers.  Therefore attempts to resolve these names result in A
-   record queries to the "com' authoritative servers.  Queries for such
-   obviously bogus glue A records occur frequently at the com/net name
-   servers.
-
-2.6.1 Recommendation
-
-   An authoritative server can detect this situation.  A trailing dot
-   missing from an NS record's RDATA always results by definition in a
-   name server name that is in the zone.  But any in-zone name server
-   should have a corresponding glue A record also in the zone.  An
-   authoritative name server should report an error when a zone's NS
-   record references an in-zone name server without a corresponding glue
-   A record.
-
-2.7 Name server records with zero TTL
-
-   Sometimes a popular com/net subdomain's zone is configured with a TTL
-   of zero on the zone's NS records, which prohibits these records from
-   being cached and will result in a higher query volume to the zone's
-   authoritative servers.  The zone's administrator should understand
-   the consequences of such a configuration and provision resources
-   accordingly.  A zero TTL on the zone's NS RRset, however, carries
-   additional consequences beyond the zone itself: if a recursive name
-   server cannot cache a zone's NS records because of a zero TTL, it
-   will be forced to query that zone's parent's name servers each time
-   it resolves a name in the zone.  The com/net authoritative servers do
-   see an increased query load when a popular com/net subdomain's zone
-   is configured with a TTL of zero on the zone's NS records.
-
-   A zero TTL on an RRset expected to change frequently is extreme but
-   permissible.  A zone's NS RRset is a special case, however, because
-   changes to it must be coordinated with the zone's parent.  In most
-   zone parent/child relationships we are aware of, there is typically
-   some delay involved in effecting changes.  Further, changes to the
-   set of a zone's authoritative name servers (and therefore to the
-   zone's NS RRset) are typically relatively rare: providing reliable
-   authoritative service requires a reasonably stable set of servers.
-   Therefore an extremely low or zero TTL on a zone's NS RRset rarely
-   makes sense, except in anticipation of an upcoming change.  In this
-   case, when the zone's administrator has planned a change and does not
-   want recursive name servers throughout the Internet to cache the NS
-   RRset for a long period of time, a low TTL is reasonable.
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 10]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-2.7.1 Recommendation
-
-   Because of the additional load placed on a zone's parent's
-   authoritative servers imposed by a zero TTL on a zone's NS RRset,
-   under such circumstances authoritative name servers should issue a
-   warning when loading a zone or refuse to load the zone altogether.
-
-2.8 Unnecessary dynamic update messages
-
-   The UPDATE message specified in RFC 2136 [6] allows an authorized
-   agent to update a zone's data on an authoritative name server using a
-   DNS message sent over the network.  Consider the case of an agent
-   desiring to add a particular resource record. Because of zone cuts,
-   the agent does not necessarily know the proper zone to which the
-   record should be added.  The dynamic update process requires that the
-   agent determine the appropriate zone so the UPDATE message can be
-   sent to one of the zone's authoritative servers (typically the
-   primary master as specified in the zone's SOA MNAME field).
-
-   The appropriate zone to update is the closest enclosing zone, which
-   is the lowest zone in the name space.  The closest enclosing zone
-   cannot be determined only by inspecting the domain name of the record
-   to be updated, since zone cuts can occur anywhere.  One way to
-   determine the closest enclosing zone involves working up the name
-   space tree and sending repeated UPDATE messages until success.  For
-   example, consider an agent attempting to add an A record with the
-   name "foo.bar.example.com".  The agent could first attempt to update
-   the "foo.bar.example.com" zone.  If the attempt failed, the update
-   could be directed to the "bar.example.com" zone, then the
-   "example.com" zone, then the "com" zone, and finally the root zone.
-
-   A popular dynamic agent follows this algorithm.  The result is many
-   UPDATE messages received by the root name servers, the com/net
-   authoritative servers, and presumably other TLD authoritative
-   servers. A reasonable question is why the algorithm proceeds with
-   sending updates all the way to TLD and root name servers.  In
-   enterprise DNS architectures with an "internal root" design, there
-   could conceivably be private, non-public TLD or root zones that would
-   be the appropriate target for a dynamic update.  However, we question
-   if designing an algorithm to accommodate these limited cases is worth
-   the load it places on the public DNS in the form of unnecessary
-   UPDATE messages.
-
-2.8.1 Recommendation
-
-   Dynamic update agents should not attempt to send UPDATE messages to
-   authoritative servers for TLD zones or the root zone by default.  If
-   this functionality is supported, it should be require specific action
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 11]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   by a user to be enabled.
-
-2.9 Queries for domain names resembling IP addresses
-
-   The root name servers receive a significant number of A record
-   queries where the qname is an IP address.  The source of these
-   queries is unknown.  It could be attributed to situations where a
-   user believes an application will accept either a domain name or an
-   IP address in a given configuration option.  The user enters an IP
-   address, but the application assumes any input is a domain name and
-   attempts to resolve it, resulting in an A record lookup.  There could
-   also be applications that produce such queries in a misguided attempt
-   to reverse map IP addresses.
-
-   These queries result in Name Error (RCODE=3) responses.  A recursive
-   name server can negatively cache such responses, but each response
-   requires a separate cache entry, i.e., a negative cache entry for the
-   domain name "192.0.2.1" does not prevent a subsequent query for the
-   domain name "192.0.2.2".
-
-2.9.1 Recommendation
-
-   It would be desirable for the root name servers not to have to answer
-   these queries: they unnecessarily consume CPU resources and network
-   bandwidth.  One possibility is for recursive name server
-   implementations to produce the Name Error response directly.  We
-   suggest that implementors consider the option of synthesizing Name
-   Error responses at the recursive name server.  The server could claim
-   authority for synthesized TLD zones corresponding to the first octet
-   of every possible IP address, e.g. 1., 2., through 255.  This
-   behavior could be configurable in the (probably unlikely) event that
-   numeric TLDs are ever put into use.
-
-   Another option is to delegate these numeric TLDs from the root zone
-   to a separate set of servers to absorb the traffic.  The "blackhole
-   servers" used by the the AS 112 Project [8], which are currently
-   delegated the in-addr.arpa zones corresponding to RFC 1918 [7]
-   private use address space, would be a possible choice to receive
-   these delegations.
-
-2.10 Misdirected recursive queries
-
-   The root name servers receive a significant number of recursive
-   queries (i.e., queries with the RD bit set in the header).  Since
-   none of the root servers offer recursion, the servers' response in
-   such a situation ignores the request for recursion and the response
-   probably does not contain the data the querier anticipated.  Some of
-   these queries result from users configuring stub resolvers to query a
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 12]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   root server.  (This situation is not hypothetical: we have received
-   complaints from users when this configuration does not work as
-   hoped.) Of course, users should not direct stub resolvers to use name
-   servers that do not offer recursion, but we are not aware of any stub
-   resolver implementation that offers any feedback to the user when so
-   configured, aside from simply "not working".
-
-2.10.1 Recommendation
-
-   When the IP address of a (supposedly) recursive name server is
-   configured in a stub resolver using an interactive user interface,
-   the resolver could send a test query to verify that the server
-   supports recursion (i.e., the response has the RA bit set in the
-   header).  The user could be immediately notified if the server is
-   non-recursive.
-
-   The stub resolver could also report an error, either through a user
-   interface or in a log file, if the queried server does not support
-   recursion.  Error reporting should be throttled to avoid a
-   notification or log message for every response from a non-recursive
-   server.
-
-2.11 Suboptimal name server selection algorithm
-
-   An entire document could be devoted to the topic of problems with
-   different implementations of the recursive resolution algorithm.  The
-   entire process of recursion is woefully underspecified, requiring
-   each implementor to design an algorithm.  Sometimes implementors make
-   poor design choices that could be avoided if a suggested algorithm
-   and best practices were documented, but that is a topic for another
-   document.
-
-   Some deficiencies cause significant operational impact and are
-   therefore worth mentioning here.  One of these is name server
-   selection by a recursive name server.  When a recursive name server
-   wants to contact one of a zone's authoritative name servers, how does
-   it choose from the NS records listed in the zone's NS RRset?  If the
-   selection mechanism is suboptimal, queries are not spread evenly
-   among a zone's authoritative servers.  The details of the selection
-   mechanism are up to the implementor, but we offer some suggestions.
-
-2.11.1 Recommendation
-
-   This list is not conclusive, but reflects the changes that would
-   produce the most impact in terms of reducing disproportionate query
-   load among a zone's authoritative servers.  I.e., these changes would
-   help spread the query load evenly.
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 13]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   o  Do not make assumptions based on NS RRset order: all NS RRs should
-      be treated equally.  (In the case of the "com" zone, for example,
-      most of the root servers return the NS record for
-      "a.gtld-servers.net" first in the authority section of referrals.
-      As a result, this server receives disproportionately more traffic
-      than the other 12 authoritative servers for "com".)
-
-   o  Use all NS records in an RRset.  (For example, we are aware of
-      implementations that hard-coded information for a subset of the
-      root servers.)
-
-   o  Maintain state and favor the best-performing of a zone's
-      authoritative servers.  A good definition of performance is
-      response time. Non-responsive servers can be penalized with an
-      extremely high response time.
-
-   o  Do not lock onto the best-performing of a zone's name servers.  A
-      recursive name server should periodically check the performance of
-      all of a zone's name servers to adjust its determination of the
-      best-performing one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 14]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-3. IANA considerations
-
-   There are no new IANA considerations introduced by this
-   Internet-Draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 15]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-4. Security considerations
-
-   Name server and resolver misbehaviors identical or similar to those
-   discussed in this document expose the root and TLD name servers to
-   increased risk of both intentional and unintentional denial of
-   service.
-
-   We believe that implementation of the recommendations offered in this
-   document will reduce the amount of unnecessary traffic seen at root
-   and TLD name servers, thus reducing the opportunity for an attacker
-   to use such queries to his or her advantage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 16]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-5. Internationalization considerations
-
-   We do not believe this document introduces any new
-   internationalization considerations to the DNS protocol
-   specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 17]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [3]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [4]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-        RFC 2181, July 1997.
-
-   [5]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-        2308, March 1998.
-
-   [6]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-        Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
-        1997.
-
-   [7]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E.
-        Lear, "Address Allocation for Private Internets", BCP 5, RFC
-        1918, February 1996.
-
-   [8]  <http://www.as112.net>
-
-
-Authors' Addresses
-
-   Matt Larson
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: mlarson@verisign.com
-
-
-   Piet Barber
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   USA
-
-   EMail: pbarber@verisign.com
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 18]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      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 (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
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 19]
-
-Internet-Draft    Observed DNS Resolution Misbehavior      February 2004
-
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber         Expires August 16, 2004                [Page 20]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
deleted file mode 100644
index 04815175fdba..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
+++ /dev/null
@@ -1,1344 +0,0 @@
-

-DNSOP                                                         O. Kolkman

-Internet-Draft                                                  RIPE NCC

-Expires: August 30, 2004                                       R. Gieben

-                                                              NLnet Labs

-                                                              March 2004

-

-

-                      DNSSEC Operational Practices

-         draft-ietf-dnsop-dnssec-operational-practices-01.txt

-

-Status of this Memo

-

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

-   all provisions of Section 10 of RFC2026.

-

-   Internet-Drafts are working documents of the Internet Engineering

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

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

-

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

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

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

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

-

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

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

-

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

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

-

-   This Internet-Draft will expire on August 30, 2004.

-

-Copyright Notice

-

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

-

-Abstract

-

-   This document describes a set of practices for operating a DNSSEC

-   aware environment.  The target audience is zone administrators

-   deploying DNSSEC that need a guide to help them chose appropriate

-   values for DNSSEC parameters.  It also discusses operational matters

-   such as key rollovers, KSK and ZSK considerations and related

-   matters.

-

-

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 1]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-Table of Contents

-

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

-     1.1   The Use of the Term 'key'  . . . . . . . . . . . . . . . .  3

-     1.2   Keeping the Chain of Trust Intact  . . . . . . . . . . . .  3

-   2.  Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . .  4

-     2.1   Time Definitions . . . . . . . . . . . . . . . . . . . . .  4

-     2.2   Time Considerations  . . . . . . . . . . . . . . . . . . .  5

-   3.  Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6

-     3.1   Motivations for the KSK and ZSK Functions  . . . . . . . .  7

-     3.2   Key Security Considerations  . . . . . . . . . . . . . . .  8

-       3.2.1   Key Validity Period  . . . . . . . . . . . . . . . . .  8

-       3.2.2   Key Algorithm  . . . . . . . . . . . . . . . . . . . .  8

-       3.2.3   Key Sizes  . . . . . . . . . . . . . . . . . . . . . .  8

-     3.3   Key Rollovers  . . . . . . . . . . . . . . . . . . . . . .  9

-       3.3.1   Zone-signing Key Rollovers . . . . . . . . . . . . . . 10

-       3.3.2   Key-signing Key Rollovers  . . . . . . . . . . . . . . 13

-   4.  Planning for Emergency Key Rollover  . . . . . . . . . . . . . 14

-     4.1   KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15

-     4.2   ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15

-     4.3   Compromises of Keys Anchored in Resolvers  . . . . . . . . 16

-   5.  Parental Policies  . . . . . . . . . . . . . . . . . . . . . . 16

-     5.1   Initial Key Exchanges and Parental Policies

-           Considerations . . . . . . . . . . . . . . . . . . . . . . 16

-     5.2   Storing Keys So Hashes Can Be Regenerated  . . . . . . . . 16

-     5.3   Security Lameness Checks . . . . . . . . . . . . . . . . . 17

-     5.4   DS Signature Validity Period . . . . . . . . . . . . . . . 17

-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17

-   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17

-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18

-   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 18

-   8.2   Informative References . . . . . . . . . . . . . . . . . . . 18

-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19

-   A.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 19

-   B.  Zone-signing Key Rollover Howto  . . . . . . . . . . . . . . . 20

-   C.  Typographic Conventions  . . . . . . . . . . . . . . . . . . . 20

-   D.  Document Details and Changes . . . . . . . . . . . . . . . . . 22

-     D.1   draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22

-     D.2   draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22

-       Intellectual Property and Copyright Statements . . . . . . . . 23

-

-

-

-

-

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 2]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-1.  Introduction

-

-   During workshops and early operational deployment tests, operators

-   and system administrators gained experience about operating DNSSEC

-   aware DNS services.  This document translates these experiences into

-   a set of practices for zone administrators. At the time of writing,

-   there exists very little experience with DNSSEC in production

-   environments, this document should therefore explicitly not be seen

-   as represented 'Best Current Practices'.

-

-   The procedures herein are focused on the maintenance of signed zones

-   (i.e. signing and publishing zones on authoritative servers). It is

-   intended that maintenance of zones such as resigning or key rollovers

-   be transparent to any verifying clients on the Internet.

-

-   The structure of this document is as follows: It begins with

-   discussing some of the considerations with respect to timing

-   parameters of DNS in relation to DNSSEC (Section 2). Aspects of key

-   management such as key rollover schemes are described in Section 3.

-   Emergency rollover considerations are addressed in Section 4.  The

-   typographic conventions used in this document are explained in

-   Appendix C.

-

-   Since this is a document with operational suggestions and there are

-   no protocol specifications, the RFC2119 [5] language does not apply.

-

-1.1  The Use of the Term 'key'

-

-   It is assumed that the reader is familiar with the concept of

-   asymmetric keys on which DNSSEC is based (Public Key Cryptography

-   [Ref to Schneider?]). Therefore, this document will use the term

-   'key' rather loosely. Where it is written that 'a key is used to sign

-   data' it is assumed that the reader understands that it is the

-   private part of the key-pair that is used for signing. It is also

-   assumed that the reader understands that the public part of the

-   key-pair is published in the DNSKEY resource record and that it is

-   used in key-exchanges.

-

-1.2  Keeping the Chain of Trust Intact

-

-   Maintaining a valid chain of trust is important because broken chains

-   of trust will result in data being marked as bogus, which may cause

-   entire (sub)domains to become invisible to verifying clients. The

-   administrators of secured zones have to realise that their zone is,

-   to their clients, part of a chain of trust.

-

-   As mentioned in the introduction, the procedures herein are intended

-   to ensure maintenance of zones, such as resigning or key rollovers,

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 3]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   be transparent to the verifying clients on the Internet.

-   Administrators of secured zones will have to keep in mind that data

-   published on an authoritative primary server will not be immediately

-   seen by verifying clients; it may take some time for the data to be

-   transfered to other secondary authoritative nameservers, during which

-   period clients may be fetching data from caching non-authoritative

-   servers.  For the verifying clients it is important that  data from

-   secured zones can be used to build chains of trust regardless of

-   whether the  data came directly from an authoritative server, a

-   caching nameserver or some middle box. Only by carefully using the

-   available timing parameters can a zone administrator  assure that the

-   data necessary for verification can be obtained.

-

-   The responsibility for maintaining the chain of trust is shared by

-   administrators of secured zones in the chain of trust. This is most

-   obvious in the case of a 'key compromise' when a trade off between

-   maintaining a valid chain of trust and the fact that the key has been

-   stolen, must be made.

-

-   The zone administrator will have to make a tradeoff between keeping

-   the chain of trust intact  -thereby allowing for attacks with the

-   compromised key- or to deliberately break the chain of trust thereby

-   making secured subdomains invisible to security aware resolvers. Also

-   see Section 4.

-

-2.  Time in DNSSEC

-

-   Without DNSSEC all times in DNS are relative. The SOA's refresh,

-   retry and expiration timers are counters that are used to determine

-   the time elapsed after a slave server syncronised (or tried to

-   syncronise) with a master server. The Time to Live (TTL) value and

-   the SOA minimum TTL parameter [6] are used to determine how long a

-   forwarder should cache data after it has been fetched from an

-   authoritative server. DNSSEC introduces the notion of an absolute

-   time in the DNS. Signatures in DNSSEC have an expiration date after

-   which the signature is marked as invalid and the signed data is to be

-   considered bogus.

-

-2.1  Time Definitions

-

-   In this document we will be using a number of time related terms.

-   Within the context of this document the following definitions apply:

-   o  "Signature validity period"

-         The period that a signature is valid. It starts at the time

-         specified in the signature inception field of the RRSIG RR and

-         ends at the time specified in the expiration field of the RRSIG

-         RR.

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 4]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   o  "Signature publication period"

-         Time after which a signature (made with a specific key) is

-         replaced with a new signature (made with the same key). This

-         replacement takes place by publishing the relevant RRSIG in the

-         master zone file.  If a signature is published at time T0 and a

-         new signature is published at time T1, the signature

-         publication period is T1 - T0.

-         If all signatures are refreshed at zone (re)signing then the

-         signature publication period is equal signature validity

-         period.

-   o  "Maximum/Minimum Zone TTL"

-         The maximum or minimum value of all the TTLs in a zone.

-

-2.2  Time Considerations

-

-   Because of the expiration of signatures, one should consider the

-   following.

-   o  The Maximum Zone TTL of your zone data should be a fraction of

-      your signature validity period.

-         If the TTL would be of similar order as the signature validity

-         period, then all RRsets fetched during the validity period

-         would be cached until the signature expiration time.  As a

-         result query load on authoritative servers would peak at

-         signature expiration time.

-         To avoid query load peaks we suggest the TTL on all the RRs in

-         your zone to be at least a few times smaller than your

-         signature validity period.

-   o  The signature publication period should be at least one maximum

-      TTL smaller than the signature validity period.

-         Resigning a zone shortly before the end of the signature

-         validity period may cause simultaneous expiration of data from

-         caches. This in turn may lead to peaks in the load on

-         authoritative servers.

-   o  The Minimum zone TTL should be long enough to both fetch and

-      verify all the RRs in the authentication chain.

-            1. During validation, some data may expire before the

-            validation is complete. The validator should be able to keep

-            all data, until is completed. This applies to all RRs needed

-            to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and

-            the final answers i.e. the RR that is returned for the

-            initial query.

-            2. Frequent verification causes load on recursive

-            nameservers. Data at delegation points, DSs, DNSKEYs and

-            RRSIGs benefit from caching. The TTL on those should be

-            relatively long.

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 5]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-         We have seen events where data needed for verification of an

-         authentication chain had expired from caches.

-         We suggest the TTL on DNSKEY and DSs to be between ten minutes

-         and one hour.  We recommend zone administrators to chose TTLs

-         longer than half a minute.

-         [Editor's Note: this observation could be implementation

-         specific. We are not sure if we should leave this item]

-   o  Slave servers will need to be able to fetch newly signed zones

-      well before the data expires from your zone.

-         'Better no answers than bad answers.'

-         If a properly implemented slave server is not able to contact a

-         master server for an extended period the data will at some

-         point expire and the slave server will not hand out any data.

-         If the server serves a DNSSEC zone than it may well happen that

-         the signatures expire well before the SOA expiration timer

-         counts down to zero. It is not possible to completely prevent

-         this from happening by tweaking the SOA parameters. However,

-         the effects can be minimized where the SOA expiration time is

-         equal or smaller than the signature validity period.

-         The consequence of an authoritative server not being able to

-         update a zone, whilst that zone includes expired signaturs, is

-         that non-secure resolvers will continue to be able to resolve

-         data served by the particular slave servers. Security aware

-         resolvers will experience problems.

-         We suggest the SOA expiration timer being approximately one

-         third or one fourth of the signature validity period. It will

-         allow problems with transfers from the master server to be

-         noticed before the actual signature time out.

-         We suggest that operators of nameservers with slave zones

-         develop 'watch dogs' to spot upcoming signature expirations in

-         slave zones, and take appropriate action.

-         When determining the value for the expiration parameter one has

-         to take the following into account: What are the chances that

-         all my secondary zones expire; How quickly can I reach an

-         administrator and load a valid zone? All these arguments are

-         not DNSSEC specific.

-

-3.  Keys

-

-   In the DNSSEC protocol there is only one type of key, the zone key.

-   With this key, the data in a zone is signed.

-

-   To make zone re-signing and key rollovers procedures easier to

-   implement, it is possible to use one or more keys as Key Signing Keys

-   (KSK) these keys will only sign the apex DNSKEY RRs in a zone. Other

-   keys can be used to sign all the RRsets in a zone and are referred to

-   as Zone Signing Keys (ZSK). In this document we assume that KSKs are

-   the subset of keys that are used for key exchanges with the parents

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 6]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   and potentially for configuration as trusted anchors - the so called

-   Secure Entry Point keys (SEP). In this document we assume a

-   one-to-one mapping between KSK and SEP keys and we assume the SEP

-   flag [4] to be set on KSKs.

-

-3.1  Motivations for the KSK and ZSK Functions

-

-   Differentiating between the KSK to ZSK functions has several

-   advantages:

-

-   o  Making the KSK stronger (i.e. using more bits in the key material)

-      has little operational impact since it is only used to sign a

-      small fraction of the zone data.

-   o  As the KSK is only used to sign a keyset, which is most probably

-      updated less frequently than other data in the zone, it can be

-      stored separately from (and thus in a safer location than) the

-      ZSK.

-   o  A KSK can be used for longer periods.

-   o  No parent/child interaction is required when ZSKs are updated.

-

-   The KSK is used less than ZSK, once a keyset is signed with the KSK

-   all the keys in the keyset can be used as ZSK. If a ZSK is

-   compromised, it can be simply dropped from the keyset. The new keyset

-   is then resigned with the KSK.

-

-   Given the assumption that for KSKs the SEP flag is set, the KSK can

-   be distinguished from a ZSK by examining the flag field in the DNSKEY

-   RR. If the flag field is an odd number it is a KSK if it is an even

-   number it is a ZSK e.g. a value of 256 and a key signing key has 257.

-

-   The zone-signing key can be used to sign all the data in a zone on a

-   regular basis. When a zone-signing key is to be rolled, no

-   interaction with the parent is needed.  This allows for relatively

-   short "Signature Validity Periods". That is, Signature Validity

-   Periods of the order of days.

-

-   The key-signing key is only to be used to sign the Key RR set from

-   the zone apex. If a key-signing key is to be rolled over, there will

-   be interactions with parties other than the zone administrator such

-   as the registry of the parent zone or administrators of verifying

-   resolvers that have the particular key configured as trusted entry

-   points. Hence, the "Key Usage Time" of these keys can and should be

-   made much longer. Although, given a long enough key, the "Key Usage

-   Time" can be on the order of years we suggest to plan for a "Key

-   Usage Time" of the order of a few months so that a key rollover

-   remains an operational routine.

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 7]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-3.2  Key Security Considerations

-

-   Keys in DNSSEC have a number of parameters which should all be chosen

-   with care, the most important once are: size, algorithm and the key

-   validity period (its lifetime).

-

-3.2.1  Key Validity Period

-

-   RFC2541 [2] describes a number of considerations with respect to the

-   security of keys. The document deals with the generation, lifetime,

-   size and storage of private keys.

-

-   In Section 3 of RFC2541 [2] there are some suggestions for a key

-   validity period: 13 months for long-lived keys and 36 days for

-   transaction keys but suggestions for key sizes are not made.

-

-   If we say long-lived keys are key-signing keys and transactions keys

-   are zone-signing keys, these recommendations will lead to rollovers

-   occurring frequently enough to become part of 'operational habits';

-   the procedure does not have to be reinvented every time a key is

-   replaced.

-

-3.2.2  Key Algorithm

-

-   We recommend you choose RSA/SHA-1 as the preferred algorithm for the

-   key. RSA has been developed in an open and transparent manner. As the

-   patent on RSA expired in 2001, its use is now also free. The current

-   known attacks on RSA can be defeated by making your key longer. As

-   the MD5 hashing algorithm is showing (theoretical) cracks, we

-   recommend the usage of SHA1.

-

-3.2.3  Key Sizes

-

-   When choosing key sizes, zone administrators will need to take into

-   account how long a key will be used and how much data will be signed

-   during the key publication period. It is hard to give precise

-   recommendations but Lenstra and Verheul [9] supplied the following

-   table with lower bound estimates for cryptographic key sizes. Their

-   recommendations are based on a set of explicitly formulated parameter

-   settings, combined with existing data points about cryptosystems. For

-   details we refer to the original paper.

-

-   [Editor's Note: DSA???]

-

-

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 8]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   	Year		RSA Key Sizes	Elliptic Curve Key Size

-   	2000		952			132

-   	2001		990			135

-   	2002		1028			139

-   	2003		1068			140

-   	2004		1108			143

-

-   	2005		1149			147

-   	2006		1191			148

-   	2007		1235			152

-   	2008		1279			155

-   	2009		1323			157

-

-

-   	2010		1369			160

-   	2011		1416			163

-   	2012		1464			165

-   	2013		1513			168

-   	2014		1562			172

-

-   	2015		1613			173

-   	2016		1664			177

-   	2017		1717			180

-   	2018		1771			181

-   	2019		1825			185

-

-

-   	2020		1881			188

-   	2021		1937			190

-   	2022		1995			193

-   	2023		2054			197

-   	2024		2113			198

-

-   	2025		2174			202

-   	2026		2236			205

-   	2027		2299			207

-   	2028		2362			210

-   	2029		2427			213

-

-   For example, should you wish your key to last three years from 2003,

-   check the RSA keysize values for 2006 in this table. In this case

-   1191.

-

-3.3  Key Rollovers

-

-   Key rollovers are a fact of life when using DNSSEC. A DNSSEC key

-   cannot be used forever (see RFC2541 [2] and Section 3.2 ).  Zone

-   administrators who are in the process of rolling their keys have to

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                 [Page 9]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   take into account that data published in previous versions of their

-   zone still lives in caches. When deploying DNSSEC, this becomes an

-   important consideration; ignoring data that may be in caches may lead

-   to loss of service for clients.

-

-   The most pressing example of this is when zone material signed with

-   an old key is being validated by a resolver which does not have the

-   old zone key cached. If the old key is no longer present in the

-   current zone, this validation fails, marking the data bogus.

-   Alternatively, an attempt could be made to validate data which is

-   signed with a new key against an old key that lives in a local cache,

-   also resulting in data being marked bogus.

-

-   To appreciate the situation one could think of a number of

-   authoritative servers that may not be instantaneously running the

-   same version of a zone and a security aware non-recursive resolver

-   that sits behind security aware caching forwarders.

-

-   Note that KSK rollovers and ZSK rollovers are different. A zone-key

-   rollover can be handled in two different ways: pre-publish (Section

-   Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The

-   pre-publish technique works because the key-signing key stays the

-   same during this ZSK rollover. With this KSK a cache is able to

-   validate the new keyset of a zone. With a KSK rollover a cache can

-   not validate the new keyset, because it does not trust the new KSK.

-

-   [Editors note: This needs more verbose explanation, nobody will

-   appreciate the situation just yet. Help with text and examples is

-   appreciated]

-

-3.3.1  Zone-signing Key Rollovers

-

-   For zone-signing key rollovers there are two ways to make sure that

-   during the rollover data still cached can be verified with the new

-   keysets or newly generated signatures can be verified with the keys

-   still in caches. One schema uses double signatures, it is described

-   in Section 3.3.1.2, the other uses key pre-publication (Section

-   3.3.1.1). The pros, cons and recommendations are described in Section

-   3.3.1.3.

-

-3.3.1.1  Pre-publish Keyset Rollover

-

-   This section shows how to perform a ZSK rollover without the need to

-   sign all the data in a zone twice - the so called "prepublish

-   rollover". We recommend this method because it has advantages in the

-   case of key compromise. If the old key is compromised, the new key

-   has already been distributed in the DNS. The zone administrator is

-   then able to quickly switch to the new key and remove the compromised

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 10]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   key from the zone. Another major advantage is that the zone size does

-   not double, as is the case with the double signature ZSK rollover. A

-   small "HOWTO" for this kind of rollover can be found in Appendix B.

-

-       normal          pre-roll         roll            after

-

-       SOA0            SOA1             SOA2            SOA3

-       RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)

-

-       DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1

-       DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11

-                       DNSKEY11         DNSKEY11

-       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)

-       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)

-

-

-   normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.

-      DNSKEY 10 is used to sign all the data of the zone, the

-      zone-signing key.

-   pre-roll: DNSKEY 11 is introduced into the keyset. Note that no

-      signatures are generated with this key yet, but this does not

-      secure against brute force attacks on the public key.  The minimum

-      duration of this pre-roll phase is the time it takes for the data

-      to propagate to the authoritative servers plus TTL value of the

-      keyset. This equates to two times the Maximum Zone TTL.

-   roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign

-      the data in the zone exclusively  (i.e. all the signatures from

-      DNSKEY 10 are removed from the zone). DNSKEY 10 remains published

-      in the keyset. This way data that was loaded into caches from

-      version 1 of the zone can still be verified with key sets fetched

-      from version 2 of the zone.

-      The minimum time that the keyset including DNSKEY 10 is to be

-      published is the time that it takes for zone data from the

-      previous version of the zone to expire from old caches i.e. the

-      time it takes for this zone to propagate to all authoritative

-      servers plus the Maximum Zone TTL value of any of the data in the

-      previous version of the zone.

-   after: DNSKEY 10 is removed from the zone. The keyset, now only

-      containing DNSKEY 11 is resigned with the DNSKEY 1.

-

-   The above scheme can be simplified by always publishing the "future"

-   key immediately after the rollover. The scheme would look as follows

-   (we show two rollovers); the future key is introduced in "after" as

-   DNSKEY 12 and again a newer one, numbered 13, in "2nd after":

-

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 11]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-       normal          roll            after           2nd roll        2nd after

-

-       SOA0            SOA2            SOA3            SOA4            SOA5

-       RRSIG10(SOA0)   RRSIG11(SOA2)   RRSIG11(SOA3)   RRSIG12(SOA4)   RRSIG12(SOA5)

-

-       DNSKEY1         DNSKEY1         DNSKEY1         DNSKEY1         DNSKEY1

-       DNSKEY10        DNSKEY10        DNSKEY11        DNSKEY11        DNSKEY12

-       DNSKEY11        DNSKEY11        DNSKEY12        DNSKEY12        DNSKEY13

-       RRSIG1(DNSKEY)  RRSIG1 (DNSKEY) RRSIG1(DNSKEY)  RRSIG1(DNSKEY)  RRSIG1(DNSKEY)

-       RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY)

-

-

-   Note that the key introduced after the rollover is not used for

-   production yet; the private key can thus be stored in a physically

-   secure manner and does not need to be 'fetched' every time a zone

-   needs to be signed.

-

-   This scheme has the benefit that the key that is intended for future

-   use: immediately during an emergency rollover assuming that the

-   private key was stored in a physically secure manner.

-

-3.3.1.2  Double Signature Zone-signing Key Rollover

-

-   This section shows how to perform a ZSK key rollover using the double

-   zone data signature scheme, aptly named "double sig rollover".

-

-   During the rollover stage the new version of the zone file will need

-   to propagate to all authoritative servers and the data that exists in

-   (distant) caches will need to expire, this will take at least the

-   maximum Zone TTL .

-

-       normal              roll              after

-

-       SOA0                SOA1              SOA2

-       RRSIG10(SOA0)       RRSIG10(SOA1)     RRSIG11(SOA2)

-                           RRSIG11(SOA1)

-

-       DNSKEY1             DNSKEY1           DNSKEY1

-       DNSKEY10            DNSKEY10          DNSKEY11

-                           DNSKEY11

-       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)    RRSIG1(DNSKEY)

-       RRSIG10(DNSKEY)     RRSIG10(DNSKEY)   RRSIG11(DNSKEY)

-                           RRSIG11(DNSKEY)

-

-   normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.

-      DNSKEY 10 is used to sign all the data of the zone, the

-      zone-signing key.

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 12]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced

-      into the keyset and all the data in the zone is signed with DNSKEY

-      10 and DNSKEY 11. The rollover period will need to exist until all

-      data from version 0 of the zone has expired from remote caches.

-      This will take at least the maximum Zone TTL of version 0 of the

-      zone.

-   after: DNSKEY 10 is removed from the zone. All the signatures from

-      DNSKEY 10 are removed from the zone. The keyset, now only

-      containing DNSKEY 11, is resigned with DNSKEY 1.

-

-   At every instance the data from the previous version of the zone can

-   be verified with the key from the current version and vice verse. The

-   data from the current version can be verified with the data from the

-   previous version of the zone. The duration of the rollover phase and

-   the period between rollovers should be at least the "Maximum Zone

-   TTL".

-

-   Making sure that the rollover phase lasts until the signature

-   expiration time of the data in version 0 of the zone is recommended.

-   However, this date could be considerably longer than the Maximum Zone

-   TTL, making the rollover a lengthy procedure.

-

-   Note that in this example we assumed that the zone was not modified

-   during the rollover. New data can be introduced in the zone as long

-   as it is signed with both keys.

-

-3.3.1.3  Pros and Cons of the Schemes

-

-   Prepublish-keyset rollover: This rollover does not involve signing

-      the zone data twice. Instead, just before the actual rollover, the

-      new key is published in the keyset and thus available for

-      cryptanalysis attacks. A small disavantage is that this process

-      requires four steps. Also the prepublish scheme will not work for

-      KSKs as explained in Section 3.3.

-   Double signature rollover: The drawback of this signing scheme is

-      that during the rollover the number of signatures in your zone

-      doubles, this may be prohibitive if you have very big zones.  An

-      advantage is that it only requires three steps.

-

-3.3.2  Key-signing Key Rollovers

-

-   For the rollover of a key-signing key the same considerations as for

-   the rollover of a zone-signing key apply. However we can use a double

-   signature scheme to guarantee that old data (only the apex keyset) in

-   caches can be verified with a new keyset and vice versa.

-

-   Since only the keyset is signed with a KSK, zone size considerations

-   do not apply.

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 13]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-       normal          roll            after

-

-       SOA0            SOA1            SOA2

-       RRSIG10(SOA0)   RRSIG10(SOA1)   RRSIG10(SOA2)

-

-       DNSKEY1         DNSKEY1         DNSKEY2

-                       DNSKEY2

-       DNSKEY10        DNSKEY10        DNSKEY10

-       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)

-                       RRSIG2 (DNSKEY)

-       RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)

-

-   normal: Version 0 of the zone.  The parental DS points to DNSKEY1.

-      Before the rollover starts the child will have to verify what the

-      TTL is of the DS RR that points to DNSKEY1 - it is needed during

-      the rollover and we refer to the value as TTL_DS.

-   roll: During the rollover phase the zone administrator generates a

-      second KSK, DNSKEY2. The key is provided to the parent and the

-      child will have to wait until a new DS RR has been generated that

-      points to DNSKEY2. After that DS RR has been published on _all_

-      servers authoritative for the parents zone, the zone administrator

-      has to wait at least TTL_DS to make sure that the old DS RR has

-      expired from distant caches.

-   after: DNSKEY1 has been removed.

-

-   The scenario above puts the responsibility for maintaining a valid

-   chain of trust with the child. It also is based on the premises that

-   the parent only has one DS RR (per algorithm) per zone. St John [The

-   draft has expired] proposed a mechanism where using an established

-   trust relation, the interaction can be performed in-band. In this

-   mechanism there are periods where there are two DS RRs at the parent.

-

-   [Editors note: We probably need to mention more]

-

-4.  Planning for Emergency Key Rollover

-

-   This section deals with preparation for a possible key compromise.

-   Our advice is to have a documented procedure ready for when a key

-   compromise is suspected or confirmed.

-

-   [Editors note: We are much in favor of a rollover tactic that keeps

-   the authentication chain intact as long as possible. This means that

-   one has to take all the regular rollover properties into account.]

-

-   When the private material of one of your keys is compromised it can

-   be used for as long as a valid authentication chain exists.  An

-   authentication chain remains intact for:

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 14]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   o  as long as a signature over the compromised key in the

-      authentication chain is valid,

-   o  as long as a parental DS RR (and signature) points to the

-      compromised key,

-   o  as long as the key is anchored in a resolver and is used as a

-      starting point for validation. (This is the hardest to update.)

-   While an authentication chain to your compromised key exists, your

-   name-space is vulnerable to abuse by the malicious key holder (i.e.

-   the owner of the compromised key). Zone operators have to make a

-   trade off if the abuse of the compromised key is worse than having

-   data in caches that cannot be validated. If the zone operator chooses

-   to break the authentication chain to the compromised key, data in

-   caches signed with this key cannot be validated. However, if the zone

-   administrator chooses to take the path of a regular roll-over, the

-   malicious key holder can spoof data so that it appears to be valid,

-   note that this kind of attack will usually be localised in the

-   Internet topology.

-

-

-4.1  KSK Compromise

-

-   When the KSK has been compromised the parent must be notified as soon

-   as possible using secure means. The keyset of the zone should be

-   resigned as soon as possible. Care must be taken to not break the

-   authentication chain. The local zone can only be resigned with the

-   new KSK after the parent's zone has been updated with the new KSK.

-   Before this update takes place it would be best to drop the security

-   status of a zone all together: the parent removes the DS of the child

-   at the next zone update.  After that the child can be made secure

-   again.

-

-   An additional danger of a key compromise is that the compromised key

-   can be used to facilitate a legitimate DNSKEY/DS and/or nameserver

-   rollover at the parent. When that happens the domain can be in

-   dispute. An out of band and secure notify mechanism to contact a

-   parent is needed in this case.

-

-4.2  ZSK Compromise

-

-   Primarily because there is no parental interaction required when a

-   ZSK is compromised, the situation is less severe than with with a KSK

-   compromise.  The zone must still be resigned with a new ZSK as soon

-   as possible. As this is a local operation and requires no

-   communication between the parent and child this can be achieved

-   fairly quickly. However, one has to take into account that just as

-   with a normal rollover the immediate disappearance from the old

-   compromised key may lead to verification problems. The

-   pre-publication scheme as discussed above minimises such problems.

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 15]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-4.3  Compromises of Keys Anchored in Resolvers

-

-   A key can also be pre-configured in resolvers. If DNSSEC is rolled

-   out as planned the root key should be pre-configured in every secure

-   aware resolver on the planet. [Editors Note: add more about

-   authentication of a newly received  resolver key]

-

-   If trust-anchor keys are compromised, the resolvers using these keys

-   should be notified of this fact. Zone administrators may consider

-   setting up a mailing list to communicate the fact that a SEP key is

-   about to be rolled over. This communication will of course need to be

-   authenticated e.g. by using digital signatures.

-

-5.  Parental Policies

-

-5.1  Initial Key Exchanges and Parental Policies Considerations

-

-   The initial key exchange is always subject to the policies set by the

-   parent (or its registry). When designing a key exchange policy one

-   should take into account that the authentication and authorisation

-   mechanisms used during a key exchange should be as strong as the

-   authentication and authorisation mechanisms used for the exchange of

-   delegation information between parent and child.

-

-   Using the DNS itself as the source for the actual DNSKEY material,

-   with an off-band check on the validity of the DNSKEY, has the benefit

-   that it reduces the chances of user error. A parental DNSKEY download

-   tool can make use of the SEP bit [4] to select the proper key from a

-   DNSSEC keyset; thereby reducing the chance that the wrong DNSKEY is

-   sent. It can validate the self-signature over a key; thereby

-   verifying the ownership of the private key material. Fetching the

-   DNSKEY from the DNS ensures that the child will not become bogus once

-   the parent publishes the DS RR indicating the child is secure.

-

-   Note: the off-band verification is still needed when the key-material

-   is fetched by a tool. The parent can not be sure whether the DNSKEY

-   RRs have been spoofed.

-

-5.2  Storing Keys So Hashes Can Be Regenerated

-

-   When designing a registry system one should consider if the DNSKEYs

-   and/or the corresponding DSs are stored. Storing DNSKEYs will help

-   during troubleshooting while the overhead of calculating DS records

-   from them is minimal.

-

-   Having an out-of-band mechanism, such as a Whois database, to find

-   out which keys are used to generate DS Resource Records for specific

-   owners may also help with troubleshooting.

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 16]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-5.3  Security Lameness Checks

-

-   Security Lameness is defined as what happens when a parent has a DS

-   Resource Record pointing to a non-existing DNSKEY RR. During key

-   exchange a parent should make sure that the child's key is actually

-   configured in the DNS before publishing a DS RR in its zone. Failure

-   to do so would render the child's zone being marked as bogus.

-

-   Child zones should be very careful removing DNSKEY material,

-   specifically SEP keys, for which a DS RR exists.

-

-   Once a zone is "security lame" a fix (e.g. by removing a DS RR) will

-   take time to propagate through the DNS.

-

-5.4  DS Signature Validity Period

-

-   Since the DS can be replayed as long as it has a valid signature a

-   short signature validity period over the DS minimises the time a

-   child is vulnerable in the case of a compromise of the child's

-   KSK(s).  A signature validity period that is too short introduces the

-   possibility that a zone is marked bogus in case of a configuration

-   error in the signer; there may not be enough time to fix the problems

-   before signatures expire.  Something as mundane as operator

-   unavailability during weekends shows the need for DS signature

-   lifetimes longer than 2 days. We recommend the minimum for a DS

-   signature validity period to be a few days.

-

-   The maximum signature lifetime of the DS record depends on how long

-   child zones are willing to be vulnerable after a key compromise. We

-   consider a signature validity period of around one week to be a good

-   compromise between the operational constraints of the parent and

-   minimising damage for the child.

-

-6.  Security Considerations

-

-   DNSSEC adds data integrity to the DNS. This document tries to assess

-   considerations to operate a stable and secure DNSSEC service. Not

-   taking into account the 'data propagation' properties in the DNS will

-   cause validation failures and may make secured zones unavailable to

-   security aware resolvers.

-

-7.  Acknowledgments

-

-   We, the folk mentioned as authors, only acted as editors. Most of the

-   ideas in this draft were the result of collective efforts during

-   workshops, discussions and try outs.

-

-   At the risk of forgetting individuals who where the original

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 17]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   contributors of the ideas we would like to acknowledge people who

-   where actively involved in the compilation of this document. In

-   random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson,

-   Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier

-   Courtay, Sam Weiler.

-

-   Emma Bretherick and Adrian Bedford corrected many of the spelling and

-   style issues.

-

-   Kolkman and Gieben take the blame for introducing all miscakes(SIC).

-

-8.  References

-

-8.1  Normative References

-

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

-        2535, March 1999.

-

-   [2]  Eastlake, D., "DNS Security Operational Considerations", RFC

-        2541, March 1999.

-

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

-        Status", RFC 3090, March 2001.

-

-   [4]  Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key

-        (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work

-        in progress), February 2003.

-

-8.2  Informative References

-

-   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement

-        Levels", BCP 14, RFC 2119, March 1997.

-

-   [6]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC

-        2308, March 1998.

-

-   [7]  Gudmundsson, O., "Delegation Signer Resource Record",

-        draft-ietf-dnsext-delegation-signer-13 (work in progress), March

-        2003.

-

-   [8]  Arends, R., "Protocol Modifications for the DNS Security

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

-        progress), March 2003.

-

-   [9]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes",

-        The Journal of Cryptology 14 (255-293), 2001.

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 18]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-Authors' Addresses

-

-   Olaf M. Kolkman

-   RIPE NCC

-   Singel 256

-   Amsterdam  1016 AB

-   The Netherlands

-

-   Phone: +31 20 535 4444

-   EMail: olaf@ripe.net

-   URI:   http://www.ripe.net/

-

-

-   Miek Gieben

-   NLnet Labs

-   Kruislaan 419

-   Amsterdam  1098 VA

-   The Netherlands

-

-   EMail: miek@nlnetlabs.nl

-   URI:   http://www.nlnetlabs.nl

-

-Appendix A.  Terminology

-

-   In this document there is some jargon used that is defined in other

-   documents. In most cases we have not copied the text from the

-   documents defining the terms but given a more elaborate explanation

-   of the meaning. Note that these explanations should not be seen as

-   authoritative.

-

-   Private and Public Keys: DNSSEC secures the DNS through the use of

-      public key cryptography. Public key cryptography is based on the

-      existence of two keys, a public key and a private key. The public

-      keys are published in the DNS by use of the DNSKEY Resource Record

-      (DNSKEY RR). Private keys should remain private i.e. should not be

-      exposed to parties not-authorised to do the actual signing.

-   Signer: The system that has access to the private key material and

-      signs the Resource Record sets in a zone. A signer may be

-      configured to sign only parts of the zone e.g. only those RRsets

-      for which existing signatures are about to expire.

-   KSK: A Key-Signing Key (KSK) is a key that is used exclusively for

-      signing the apex keyset.  The fact that a key is a KSK is only

-      relevant to the signing tool.

-   ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all

-      data in a zone.  The fact that a key is a ZSK is only relevant to

-      the signing tool.

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 19]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   SEP Key: A KSK that has a parental DS record pointing to it. Note:

-      this is not enforced in the protocol. A SEP Key with no parental

-      DS is security lame.

-   Anchored Key: A DNSKEY configured in resolvers around the globe. This

-      Key is hard to update, hence the term anchored.

-   Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked

-      "Bogus" when a signature of a RRset does not validate against the

-      DNSKEY. Even if the key itself was not marked Bogus. A cache may

-      choose to cache Bogus data for various reasons.

-   Singing the Zone File: The term used for the event where an

-      administrator joyfully signs its zone file while producing melodic

-      sound patterns.

-   Zone Administrator: The 'role' that is responsible for signing a zone

-      and publishing it on the primary authoritative server.

-

-Appendix B.  Zone-signing Key Rollover Howto

-

-   Using the pre-published signature scheme and the most conservative

-   method to assure oneself that data does not live in distant caches

-   here follows the "HOWTO". [WES: has some comments about this]

-   Key notation:

-   Step 0: The preparation: Create two keys and publish both in your

-      keyset.  Mark one of the keys as "active" and the other as

-      "published". Use the "active" key for signing your zone data.

-      Store the private part of the "published" key, preferably

-      off-line.

-   Step 1: Determine expiration: At the beginning of the rollover make a

-      note of the highest expiration time of signatures in your zone

-      file created with the current key marked as "active".

-      Wait until the expiration time marked in Step 1 has passed

-   Step 2: Then start using the key that was marked as "published" to

-      sign your data i.e. mark it as "active". Stop using the key that

-      was marked as "active", mark it as "rolled".

-   Step 3: It is safe to engage in a new rollover (Step 1) after at

-      least one "signature validity period".

-

-Appendix C.  Typographic Conventions

-

-   The following typographic conventions are used in this document:

-   Key notation: A key is denoted by KEYx, where x is a number, x could

-      be thought of as the key id.

-   RRset notations: RRs are only denoted by the type. All other

-      information - owner, class, rdata and TTL - is left out. Thus:

-      example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a

-      list of RRs. A example of this would be: A1,A2, specifying the

-      RRset containing two A records. This could again be abbreviated to

-      just: A.

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 20]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-   Signature notation: Signatures are denoted as RRSIGx(RRset), which

-      means that RRset is signed with DNSKEYx.

-   Zone representation: Using the above notation we have simplified the

-      representation of a signed zone by leaving out all unnecessary

-      details such as the names and by  representing all data by "SOAx"

-   SOA representation: SOA's are represented as SOAx, where x is the

-      serial number.

-   Using this notation the following zone :

-

-

-   example.net.      600     IN SOA  ns.example.net. ernie.example.net. (

-                                     10         ; serial

-                                     450        ; refresh (7 minutes 30 seconds)

-                                     600        ; retry (10 minutes)

-                                     345600     ; expire (4 days)

-                                     300        ; minimum (5 minutes)

-                                     )

-                     600     RRSIG   SOA 5 2 600 20130522213204 (

-                                     20130422213204 14 example.net.

-                                     cmL62SI6iAX46xGNQAdQ... )

-                     600     NS      a.iana-servers.net.

-                     600     NS      b.iana-servers.net.

-                     600     RRSIG   NS 5 2 600 20130507213204 (

-                                     20130407213204 14 example.net.

-                                     SO5epiJei19AjXoUpFnQ ... )

-                     3600    DNSKEY  256 3 5 (

-                                     EtRB9MP5/AvOuVO0I8XDxy0...

-                                     ) ; key id = 14

-                     3600    DNSKEY  256 3 5 (

-                                     gsPW/Yy19GzYIY+Gnr8HABU...

-                                     ) ; key id = 15

-                     3600    RRSIG   DNSKEY 5 2 3600 20130522213204 (

-                                     20130422213204 14 example.net.

-                                     J4zCe8QX4tXVGjV4e1r9... )

-                     3600    RRSIG   DNSKEY 5 2 3600 20130522213204 (

-                                     20130422213204 15 example.net.

-                                     keVDCOpsSeDReyV6O... )

-                     600     NSEC    a.example.net. NS SOA TXT RRSIG DNSKEY NSEC

-                     600     RRSIG   NSEC 5 2 600 20130507213204 (

-                                     20130407213204 14 example.net.

-                                     obj3HEp1GjnmhRjX... )

-   a.example.net.    600     IN TXT  "A label"

-                     600     RRSIG   TXT 5 3 600 20130507213204 (

-                                     20130407213204 14 example.net.

-                                     IkDMlRdYLmXH7QJnuF3v... )

-                     600     NSEC    b.example.com. TXT RRSIG NSEC

-                     600     RRSIG   NSEC 5 3 600 20130507213204 (

-                                     20130407213204 14 example.net.

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 21]

-

-Internet-Draft        DNSSEC Operational Practices            March 2004

-

-

-                                     bZMjoZ3bHjnEz0nIsPMM... )

-

-                     ...

-

-

-    is reduced to the following represenation:

-

-       SOA10

-       RRSIG14(SOA10)

-

-       DNSKEY14

-       DNSKEY15

-

-       RRSIG14(KEY)

-       RRSIG15(KEY)

-

-    The rest of the zone data has the same signature as the SOA record,

-   i.e a RRSIG created with DNSKEY 14.

-

-Appendix D.  Document Details and Changes

-

-   This section is to be removed by the RFC editor if and when the

-   document is published.

-

-   $Header: /var/cvs/dnssec-key/

-   draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12

-   08:29:11 dnssec Exp $

-

-D.1  draft-ietf-dnsop-dnssec-operational-practices-00

-

-   Submission as working group document. This document is a modified and

-   updated version of draft-kolkman-dnssec-operational-practices-00.

-

-D.2  draft-ietf-dnsop-dnssec-operational-practices-01

-

-   changed the definition of "Bogus" to reflect the one in the protocol

-   draft.

-

-   Bad to Bogus

-

-   Style and spelling corrections

-

-   KSK - SEP mapping made explicit.

-

-   Updates from Sam Weiler added

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 22]

-

-Internet-Draft        DNSSEC Operational Practices            March 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

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 23]

-

-Internet-Draft        DNSSEC Operational Practices            March 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.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Kolkman & Gieben        Expires August 30, 2004                [Page 24]

-

-

diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
deleted file mode 100644
index 42c3c0b7c7e3..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
+++ /dev/null
@@ -1,1321 +0,0 @@
-
-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/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
deleted file mode 100644
index b14f711d5314..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
+++ /dev/null
@@ -1,1969 +0,0 @@
-
-
-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/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
deleted file mode 100644
index 2311ee6c18a0..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
+++ /dev/null
@@ -1,391 +0,0 @@
-
-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/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
deleted file mode 100644
index 1094275d3e40..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
-
-IETF DNSOP Working Group                                    Y. Morishita
-Internet-Draft                                                      JPRS
-Expires: July 11, 2004                                         T. Jinmei
-                                                                 Toshiba
-                                                        January 11, 2004
-
-
-       Common Misbehavior against DNS Queries for IPv6 Addresses
-            draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   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 11, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-   There is some known misbehavior of DNS authoritative servers when
-   they are queried for AAAA resource records. Such behavior can block
-   IPv4 communication which should actually be available, cause a
-   significant delay in name resolution, or even make a denial of
-   service attack. This memo describes details of the known cases and
-   discusses the effect of the cases.
-
-1. Introduction
-
-   Many DNS clients (resolvers) that support IPv6 first search for AAAA
-   Resource Records (RRs) of a target host name, and then for A RRs of
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 1]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-   the same name. This fallback mechanism is based on the DNS
-   specifications, which if not obeyed by authoritative servers can
-   produce unpleasant results. In some cases, for example, a web browser
-   fails to connect to a web server it could otherwise. In the following
-   sections, this memo describes some typical cases of the misbehavior
-   and its (bad) effects.
-
-   Note that the misbehavior is not specific to AAAA RRs. In fact, all
-   known examples also apply to the cases of queries for MX, NS, and SOA
-   RRs. The authors even believe this can be generalized for all types
-   of queries other than those for A RRs. In this memo, however, we
-   concentrate on the case for AAAA queries, since the problem is
-   particularly severe for resolvers that support IPv6, which thus
-   affects many end users. Resolvers at end users normally send A and/or
-   AAAA queries only, and so the problem for the other cases is
-   relatively minor.
-
-2. Network Model
-
-   In this memo, we assume a typical network model of name resolution
-   environment using DNS. It consists of three components; stub
-   resolvers, caching servers, and authoritative servers. A stub
-   resolver issues a recursive query to a caching server, which then
-   handles the entire name resolution procedure recursively. The caching
-   server caches the result of the query as well as sends the result to
-   the stub resolver. The authoritative servers respond to queries for
-   names for which they have the authority, normally in a non-recursive
-   manner.
-
-3. Expected Behavior
-
-   Suppose that an authoritative server has an A RR but not a AAAA RR
-   for a host name. Then the server should return a response to a query
-   for a AAAA RR of the name with the RCODE being 0 (indicating no
-   error) and with an empty answer section [1]. Such a response
-   indicates that there is at least one RR of a different type than AAAA
-   for the queried name, and the stub resolver can then look for A RRs.
-
-   This way, the caching server can cache the fact that the queried name
-   does not have a AAAA RR (but may have other types of RRs), and thus
-   can improve the response time to further queries for a AAAA RR of the
-   name.
-
-4. Problematic Behaviors
-
-   There are some known cases at authoritative servers that do not
-   conform to the expected behavior. This section describes those
-   problematic cases.
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 2]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-4.1 Return NXDOMAIN
-
-   This type of server returns a response with the RCODE being 3
-   (NXDOMAIN) to a query for a AAAA RR, indicating it does not have any
-   RRs of any type for the queried name.
-
-   With this response, the stub resolver may immediately give up and
-   never fall back. Even if the resolver retries with a query for an A
-   RR, the negative response for the name has been cached in the caching
-   server, and the caching server will simply return the negative
-   response. As a result, the stub resolver considers this as a fatal
-   error in name resolution.
-
-   There have been several known examples of this behavior, but all the
-   examples that the authors know have changed their behavior as of this
-   writing.
-
-4.2 Return NOTIMP
-
-   Other authoritative servers return a response with the RCODE being 4
-   (NOTIMP), indicating the servers do not support the requested type of
-   query.
-
-   This case is less harmful than the previous one; if the stub resolver
-   falls back to querying for an A RR, the caching server will process
-   the query correctly and return an appropriate response.
-
-   In this case, the caching server does not cache the fact that the
-   queried name has no AAAA RR, resulting in redundant queries for AAAA
-   RRs in the future. The behavior will waste network bandwidth and
-   increase the load of the authoritative server.
-
-   Using SERVFAIL or FORMERR would cause the same effect, though the
-   authors have not seen such implementations yet.
-
-4.3 Return a Broken Response
-
-   Another different type of authoritative servers returns broken
-   responses to AAAA queries. A known behavior of this category is to
-   return a response whose RR type is AAAA, but the length of the RDATA
-   is 4 bytes. The 4-byte data looks like the IPv4 address of the
-   queried host name. That is, the RR in the answer section would be
-   described like this:
-
-     www.bad.example. 600 IN AAAA 192.0.2.1
-
-   which is, of course, bogus (or at least meaningless).
-
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 3]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-   A widely deployed caching server implementation transparently returns
-   the broken response (as well as caches it) to the stub resolver.
-   Another known server implementation parses the response by
-   themselves, and sends a separate response with the RCODE being 2
-   (SERVFAIL).
-
-   In either case, the broken response does not affect queries for an A
-   RR of the same name. If the stub resolver falls back to A queries, it
-   will get an appropriate response.
-
-   The latter case, however, causes the same bad effect as that
-   described in the previous section: redundant queries for AAAA RRs.
-
-4.4 Make Lame Delegation
-
-   Some authoritative servers respond to AAAA queries in a way causing
-   lame delegation. In this case the parent zone specifies that the
-   authoritative server should have the authority of a zone, but the
-   server does not return an authoritative response for AAAA queries
-   within the zone (i.e., the AA bit in the response is not set). On the
-   other hand, the authoritative server returns an authoritative
-   response for A queries.
-
-   When a caching server asks the server for AAAA RRs in the zone, it
-   recognizes the delegation is lame, and return a response with the
-   RCODE being 2 (SERVFAIL) to the stub resolver.
-
-   Furthermore, some caching servers record the authoritative server as
-   lame for the zone and will not use it for a certain period of time.
-   With this type of caching server, even if the stub resolver falls
-   back to querying for an A RR, the caching server will simply return a
-   response with the RCODE being SERVFAIL, since all the servers are
-   known to be "lame."
-
-   There is also an implementation that relaxes the behavior a little
-   bit. It basically tries to avoid using the lame server, but still
-   continues to try it as a last resort. With this type of caching
-   server, the stub resolver will get a correct response if it falls
-   back after SERVFAIL. However, this still causes redundant AAAA
-   queries as explained in the previous sections.
-
-4.5 Ignore Queries for AAAA
-
-   Some authoritative severs seem to ignore queries for a AAAA RR,
-   causing a delay at the stub resolver to fall back to a query for an A
-   RR. This behavior may even cause a fatal timeout at the resolver.
-
-
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 4]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-5. Security Considerations
-
-   The CERT/CC pointed out that the response with NXDOMAIN described in
-   Section 4.1 can be used for a denial of service attack [2]. The same
-   argument applies to the case of "lame delegation" described in
-   Section 4.4 with a certain type of caching server.
-
-6. Acknowledgements
-
-   Erik Nordmark encouraged the authors to publish this document as an
-   Internet Draft. Akira Kato and Paul Vixie reviewed a preliminary
-   version of this document. Pekka Savola carefully reviewed a previous
-   version and provided detailed comments.
-
-Informative References
-
-   [1]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
-        1034, November 1987.
-
-   [2]  The CERT Coordination Center, "Incorrect NXDOMAIN responses from
-        AAAA queries could cause denial-of-service conditions", March
-        2003, <http://www.kb.cert.org/vuls/id/714121>.
-
-
-Authors' Addresses
-
-   MORISHITA Orange Yasuhiro
-   Research and Development Department, Japan Registry Service Co.,Ltd.
-   Fuundo Bldg 3F, 1-2 Kanda-Ogawamachi
-   Chiyoda-ku, Tokyo  101-0052
-   Japan
-
-   EMail: yasuhiro@jprs.co.jp
-
-
-   JINMEI Tatuya
-   Corporate Research & Development Center, Toshiba Corporation
-   1 Komukai Toshiba-cho, Saiwai-ku
-   Kawasaki-shi, Kanagawa  212-8582
-   Japan
-
-   EMail: jinmei@isl.rdc.toshiba.co.jp
-
-Appendix A. Live Examples
-
-   In this appendix, we show concrete implementations and domain names
-   that may cause problematic cases so that the behavior can be
-   reproduced in a practical environment. The examples are for
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 5]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-   informational purposes only, and the authors do not intend to accuse
-   any implementations or zone administrators.
-
-   The behavior described in Section 4.2 (return NOTIMP) can be found by
-   looking for a AAAA RR of www.css.vtext.com at 66.174.3.4.
-
-   The behavior described in Section 4.3 (broken responses) can be seen
-   by querying for a AAAA RR of "www.gslb.mainichi.co.jp," which is an
-   alias of "www.mainichi.co.jp," at 210.173.172.2. The same behavior
-   can be found with the name "vip.alt.ihp.sony.co.jp," an alias of
-   "www.sony.co.jp," at 210.139.255.204.
-
-   The behavior described in Section 4.4 (lame delegation) can be found
-   by querying for a AAAA RR of "www.ual.com" at 209.87.113.4.
-
-   The behavior described in Section 4.5 (ignore queries) can be seen by
-   trying to ask for a AAAA RR of "ad.3jp.doubleclick.net," which is an
-   alias of "ad.jp.doubleclick.net," at 210.153.90.9.
-
-   Many authoritative server implementations show the expected behavior
-   described in Section 3. Some DNS load balancers reportedly have a
-   problematic behavior shown in Section 4, but the authors do not have
-   a concrete example. The CERT/CC provides a list of implementations
-   that behave as described in Section 4.1 [2].
-
-   The BIND9 caching server implementation is an example of the latter
-   cases described in Section 4.3 and Section 4.4, respectively. The
-   BIND8 caching server implementation is an example of the former case
-   described in Section 4.3. As for the issue shown in Section 4.4,
-   BIND8 caching servers prior to 8.3.5 show the behavior described as
-   the former case in this section. The versions 8.3.5 and later of
-   BIND8 caching server behave like the BIND9 caching server
-   implementation with this matter.
-
-   Regarding resolver implementations, the authors are only familiar
-   with the ones derived from the BIND implementation. These
-   implementations always fall back regardless of the RCODE; NXDOMAIN,
-   NOTIMP, or SERVFAIL. It even falls back when getting a broken
-   response. However, the behavior does not help the situation in the
-   NXDOMAIN case (see Section 4.1). Lame delegation (Section 4.4) also
-   causes a fatal error at the resolver side if the resolver is using
-   some older versions of BIND8 caching server.
-
-   The authors hear that a stub resolver routine implemented in some web
-   browsers interprets the broken response described in Section 4.3 as a
-   fatal error and does not fall back to A queries. However, we have not
-   confirmed this information.
-
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 6]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-Appendix B. Change History
-
-   Changes since draft-morishita-dnsop-misbehavior-against-aaaa-00 are:
-
-   o  Made a separate appendix and moved live examples to appendix so
-      that we can remove them when this document is (ever) officially
-      published.
-
-   o  Revised some live examples based on the recent status.
-
-   o  Noted in introduction that the misbehavior is not specific to AAAA
-      and that this document still concentrates on the AAAA case.
-
-   o  Changed the section title of "delegation loop" to "lame
-      delegation" in order to reflect the essential point of the issue.
-      Wording on this matter was updated accordingly.
-
-   o  Updated the Acknowledgements list.
-
-   o  Changed the reference category from normative to informative (this
-      is an informational document after all).
-
-   o  Changed the draft name to an IETF dnsop working group document (as
-      agreed).
-
-   o  Applied several editorial fixes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 7]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 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
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 8]
-
-Internet-Draft    Common Misbehavior against AAAA Queries   January 2004
-
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Morishita & Jinmei       Expires July 11, 2004                  [Page 9]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt
deleted file mode 100644
index f6ece8821034..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt
+++ /dev/null
@@ -1,485 +0,0 @@
-   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/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt
deleted file mode 100644
index b593c57179e3..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-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/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt b/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt
deleted file mode 100644
index 423a119f39f8..000000000000
--- a/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt
+++ /dev/null
@@ -1,951 +0,0 @@
-
-
-IPSECKEY WG                                                M. Richardson
-Internet-Draft                                                       SSW
-|Expires: August 1, 2004                                   February 2004
-
-
-           A Method for Storing IPsec Keying Material in DNS
-|                    draft-ietf-ipseckey-rr-09.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-|  This Internet-Draft will expire on August 1, 2004.
-
-Copyright Notice
-
-|  Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-|  This document describes a new resource record for Domain Name System
-|  (DNS).  This record may be used to store public keys for use in IP
-|  security (IPsec) systems.  The record also includes provisions for
-|  indicating what system should be contacted when establishing an IPsec
-|  tunnel with the entity in question.
-
-   This record replaces the functionality of the sub-type #1 of the KEY
-   Resource Record, which has been obsoleted by RFC3445.
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 1]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-|  1.2 Use of reverse (in-addr.arpa) map  . . . . . . . . . . . . . .  3
-|  1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . .  3
-|  2.  Storage formats  . . . . . . . . . . . . . . . . . . . . . . .  5
-|  2.1 IPSECKEY RDATA format  . . . . . . . . . . . . . . . . . . . .  5
-|  2.2 RDATA format - precedence  . . . . . . . . . . . . . . . . . .  5
-|  2.3 RDATA format - gateway type  . . . . . . . . . . . . . . . . .  5
-|  2.4 RDATA format - algorithm type  . . . . . . . . . . . . . . . .  6
-|  2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . .  6
-|  2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . .  6
-|  3.  Presentation formats . . . . . . . . . . . . . . . . . . . . .  8
-|  3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . .  8
-|  3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-|  4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-|  4.1 Active attacks against unsecured IPSECKEY resource records . . 10
-|  5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-|  6.  Intellectual Property Claims . . . . . . . . . . . . . . . . . 13
-|  7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
-|      Normative references . . . . . . . . . . . . . . . . . . . . . 15
-|      Non-normative references . . . . . . . . . . . . . . . . . . . 16
-|      Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
-|      Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 2]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-1. Introduction
-
-   It postulated that there is an end system desiring to establish an
-   IPsec tunnel with some remote entity on the network.  This system,
-   having only a DNS name of some kind (forward, reverse or even
-   user@FQDN) needs a public key to authenticate the remote entity.  It
-   also desires some guidance about whether to contact the entity
-   directly, or whether to contact another entity, as the gateway to
-   that desired entity.
-
-   The IPSECKEY RR provides a storage mechanism for such items as the
-   public key, and the gateway information.
-
-   The type number for the IPSECKEY RR is TBD.
-
-1.1 Overview
-
-   The IPSECKEY resource record (RR) is used to publish a public key
-   that is to be associated with a Domain Name System (DNS) name for use
-   with the IPsec protocol suite.  This can be the  public key of a
-   host, network, or application (in the case of per-port keying).
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC2119 [7].
-
-|1.2 Use of reverse (in-addr.arpa) map
-
-|  Often a security gateway will only have access to the IP address to
-|  which communication is desired.  It will not know the forward name.
-|  As such, it will frequently be the case that the IP address will be
-|  used an index into the reverse map.
-
-|  The lookup is done in the usual fashion as for PTR records.  The IP
-|  address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
-|  under the .arpa.  zone.  Any CNAMEs or DNAMEs found SHOULD be
-|  followed.
-
-|  Note: even when the IPsec function is the end-host, often only the
-|  application will know the forward name used.  While the case where
-|  the application knows the forward name is common, the user could
-|  easily have typed in a literal IP address.  This storage mechanism
-|  does not preclude using the forward name when it is available, but
-|  does not require it.
-
-|1.3 Usage Criteria
-
-   An IPSECKEY resource record SHOULD be used in combination with DNSSEC
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 3]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-   unless some other means of authenticating the IPSECKEY resource
-   record is available.
-
-   It is expected that there will often be multiple IPSECKEY resource
-   records at the same name.  This will be due to the presence of
-   multiple gateways and the need to rollover keys.
-
-   This resource record is class independent.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 4]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-2. Storage formats
-
-2.1 IPSECKEY RDATA format
-
-   The RDATA for an IPSECKEY RR consists of a precedence value, a
-   gateway type, a public key, algorithm type, and an optional gateway
-   address.
-
-       0                   1                   2                   3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |  precedence   | gateway type  |  algorithm  |     gateway     |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
-      ~                            gateway                            ~
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                                                               /
-      /                          public key                           /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-
-2.2 RDATA format - precedence
-
-   This is an 8-bit precedence for this record.  This is interpreted in
-   the same way as the PREFERENCE field described in section 3.3.9 of
-   RFC1035 [2].
-
-   Gateways listed in IPSECKEY records with  lower precedence are to be
-   attempted first.  Where there is a tie in precedence, the order
-   should be non-deterministic.
-
-2.3 RDATA format - gateway type
-
-   The gateway type field indicates the format of the information that
-   is stored in the gateway field.
-
-   The following values are defined:
-
-   0  No gateway is present
-
-   1  A 4-byte IPv4 address is present
-
-   2  A 16-byte IPv6 address is present
-
-   3  A wire-encoded domain name is present.  The wire-encoded format is
-      self-describing, so the length is implicit.  The domain name MUST
-      NOT be compressed.  (see section 3.3 of RFC1035 [2]).
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 5]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-2.4 RDATA format - algorithm type
-
-   The algorithm type field identifies the public key's cryptographic
-   algorithm and determines the format of the public key field.
-
-   A value of 0 indicates that no key is present.
-
-   The following values are defined:
-
-   1  A DSA key is present, in the format defined in RFC2536 [10]
-
-   2  A RSA key is present, in the format defined in RFC3110 [11]
-
-
-2.5 RDATA format - gateway
-
-   The gateway field indicates a gateway to which an IPsec tunnel may be
-   created in order to reach the entity named by this resource record.
-
-   There are three formats:
-
-   A 32-bit IPv4 address is present in the gateway field.  The data
-   portion is an IPv4 address as described in section 3.4.1 of RFC1035
-   [2].  This is a 32-bit number in network byte order.
-
-   A 128-bit IPv6 address is present in the gateway field.  The data
-   portion is an IPv6 address as described in section 2.2 of RFC3596
-   [13].  This is a 128-bit number in network byte order.
-
-   The gateway field is a normal wire-encoded domain name, as described
-   in section 3.3 of RFC1035 [2].  Compression MUST NOT be used.
-
-2.6 RDATA format - public keys
-
-   Both of the public key types defined in this document (RSA and DSA)
-   inherit their public key formats from the corresponding KEY RR
-   formats.  Specifically, the public key field contains the algorithm-
-   specific portion of the KEY RR RDATA, which is all of the KEY RR DATA
-   after the first four octets.  This is the same portion of the KEY RR
-   that must be specified by documents that define a DNSSEC algorithm.
-   Those documents also specify a message digest to be used for
-   generation of SIG RRs; that specification is not relevant for
-   IPSECKEY RR.
-
-   Future algorithms, if they are to be used by both DNSSEC (in the KEY
-   RR) and IPSECKEY, are likely to use the same public key encodings in
-   both records.  Unless otherwise specified, the IPSECKEY public key
-   field will contain the algorithm-specific portion of the KEY RR RDATA
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 6]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-   for the corresponding algorithm.  The algorithm must still be
-   designated for use by IPSECKEY, and an IPSECKEY algorithm type number
-   (which might be different than the DNSSEC algorithm number) must be
-   assigned to it.
-
-   The DSA key format is defined in RFC2536 [10]
-
-   The RSA key format is defined in RFC3110 [11], with the following
-   changes:
-
-   The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
-   modulus to 2552 bits in length.  RFC3110 extended that limit to 4096
-   bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no length limit on
-   RSA public keys, other than the 65535 octet limit imposed by the two-
-   octet length encoding.  This length extension is applicable only to
-   IPSECKEY and not to KEY RRs.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 7]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-3. Presentation formats
-
-3.1 Representation of IPSECKEY RRs
-
-   IPSECKEY RRs may appear in a zone data master file.  The precedence,
-   gateway type and algorithm and gateway fields are REQUIRED.  The
-   base64 encoded public key block is OPTIONAL; if not present, then the
-   public key field of the resource record MUST be construed as being
-   zero octets in length.
-
-   The algorithm field is an unsigned integer.  No mnemonics are
-   defined.
-
-   If no gateway is to be indicated, then the gateway type field MUST be
-   zero, and the gateway field MUST be "."
-
-   The Public Key field is represented as a Base64 encoding of the
-   Public Key.  Whitespace is allowed within the Base64 text.  For a
-   definition of Base64 encoding, see RFC3548 [6] Section 5.2.
-
-   The general presentation for the record as as follows:
-
-   IN     IPSECKEY ( precedence gateway-type algorithm
-                     gateway base64-encoded-public-key )
-
-
-3.2 Examples
-
-   An example of a node 192.0.2.38 that will accept IPsec tunnels on its
-   own behalf.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
-                    192.0.2.38
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 192.0.2.38 that has published its key only.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
-                    .
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 192.0.2.38 that has delegated authority to the
-   node 192.0.2.3.
-
-   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
-                    192.0.2.3
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 8]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-   An example of a node, 192.0.1.38 that has delegated authority to the
-   node with the identity "mygateway.example.com".
-
-   38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
-                    mygateway.example.com.
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-   An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has
-   delegated authority to the node 2001:0DB8:c000:0200:2::1
-
-   $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
-   0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
-                    2001:0DB8:0:8002::2000:1
-                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                 [Page 9]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-4. Security Considerations
-
-   This entire memo pertains to the provision of public keying material
-   for use by key management protocols such as ISAKMP/IKE (RFC2407) [8].
-
-   The IPSECKEY resource record contains information that SHOULD be
-   communicated to the end client in an integral fashion - i.e.  free
-   from modification.  The form of this channel is up to the consumer of
-   the data - there must be a trust relationship between the end
-   consumer of this resource record and the server.  This relationship
-   may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
-   another secure source, a secure local channel on the host, or some
-   combination of the above.
-
-   The keying material provided by the IPSECKEY resource record is not
-   sensitive to passive attacks.  The keying material may be freely
-   disclosed to any party without any impact on the security properties
-   of the resulting IPsec session: IPsec and IKE provide for defense
-   against both active and passive attacks.
-
-   Any derivative standard that makes use of this resource record MUST
-   carefully document their trust model, and why the trust model of
-   DNSSEC is appropriate, if that is the secure channel used.
-
-4.1 Active attacks against unsecured IPSECKEY resource records
-
-   This section deals with active attacks against the DNS.  These
-   attacks require that DNS requests and responses be intercepted and
-   changed.  DNSSEC is designed to defend against attacks of this kind.
-
-   The first kind of active attack is when the attacker replaces the
-   keying material with either a key under its control or with garbage.
-
-   If the attacker is not able to mount a subsequent man-in-the-middle
-   attack on the IKE negotiation after replacing the public key, then
-   this will result in a denial of service, as the authenticator used by
-   IKE would fail.
-
-   If the attacker is able to both to mount active attacks against DNS
-   and is also in a position to perform a man-in-the-middle attack on
-   IKE and IPsec negotiations, then the attacker will be in a position
-   to compromise the resulting IPsec channel.  Note that an attacker
-   must be able to perform active DNS attacks on both sides of the IKE
-   negotiation in order for this to succeed.
-
-   The second kind of active attack is one in which the attacker
-   replaces the the gateway address to point to a node under the
-   attacker's control.  The attacker can then either replace the public
-
-
-
-|Richardson              Expires August 1, 2004                [Page 10]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-   key or remove it, thus providing an IPSECKEY record of its own to
-   match the gateway address.
-
-   This later form creates a simple man-in-the-middle since the attacker
-   can then create a second tunnel to the real destination.  Note that,
-   as before, this requires that the attacker also mount an active
-   attack against the responder.
-
-   Note that the man-in-the-middle can not just forward cleartext
-   packets to the original destination.  While the destination may be
-   willing to speak in the clear, replying to the original sender, the
-   sender will have already created a policy expecting ciphertext.
-   Thus, the attacker will need to intercept traffic from both sides.
-   In some cases, the attacker may be able to accomplish the full
-   intercept by use of Network Addresss/Port Translation (NAT/NAPT)
-   technology.
-
-|  Note that risk of a man-in-the-middle attack mediated by the IPSECKEY
-|  RR only applies to cases where the gateway field of the IPSECKEY RR
-|  indicates a different entity than the owner name of the IPSECKEY RR.
-
-|  An active attack on the DNS that caused the wrong IP address to be
-|  retrieved (via forged A RR), and therefore the wrong QNAME to be
-|  queried would also result in a man-in-the-middle attack.  This
-|  situation exists independantly of whether or not the IPSECKEY RR is
-|  used.
-
-|  In cases where the end-to-end integrity of the IPSECKEY RR is
-|  suspect, the end client MUST restrict its use of the IPSECKEY RR to
-|  cases where the RR owner name matches the content of the gateway
-|  field.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 11]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-5. IANA Considerations
-
-   This document updates the IANA Registry for DNS Resource Record Types
-   by assigning type X to the IPSECKEY record.
-
-   This document creates two new IANA registries, both specific to the
-   IPSECKEY Resource Record:
-
-   This document creates an IANA registry for the algorithm type field.
-
-   Values 0, 1 and 2 are defined in Section 2.4.  Algorithm numbers 3
-   through 255 can be assigned by IETF Consensus (see RFC2434 [5]).
-
-   This document creates an IANA registry for the gateway type field.
-
-   Values 0, 1, 2 and 3 are defined in Section 2.3.  Gateway type
-   numbers 4 through 255 can be assigned by Standards Action (see
-   RFC2434 [5]).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 12]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-6. Intellectual Property Claims
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 13]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-7. Acknowledgments
-
-   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
-   Austein, and Olafur Gurmundsson who reviewed this document carefully.
-   Additional thanks to Olafur Gurmundsson for a reference
-   implementation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 14]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-Normative references
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
-        9, RFC 2026, October 1996.
-
-   [4]  Eastlake, D. and C. Kaufman, "Domain Name System Security
-        Extensions", RFC 2065, January 1997.
-
-   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [6]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-        RFC 3548, July 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 15]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-Non-normative references
-
-   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [8]   Piper, D., "The Internet IP Security Domain of Interpretation
-         for ISAKMP", RFC 2407, November 1998.
-
-   [9]   Eastlake, D., "Domain Name System Security Extensions", RFC
-         2535, March 1999.
-
-   [10]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
-         (DNS)", RFC 2536, March 1999.
-
-   [11]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
-         System (DNS)", RFC 3110, May 2001.
-
-   [12]  Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
-         Record (RR)", RFC 3445, December 2002.
-
-   [13]  Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
-         Extensions to Support IP Version 6", RFC 3596, October 2003.
-
-
-Author's Address
-
-   Michael C. Richardson
-   Sandelman Software Works
-   470 Dawson Avenue
-   Ottawa, ON  K1Z 5V7
-   CA
-
-   EMail: mcr@sandelman.ottawa.on.ca
-   URI:   http://www.sandelman.ottawa.on.ca/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 16]
-
-|Internet-Draft   Storing IPsec keying material in DNS     February 2004
-
-
-Full Copyright Statement
-
-|  Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-|Richardson              Expires August 1, 2004                [Page 17]