aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDoug Barton <dougb@FreeBSD.org>2006-01-14 02:11:56 +0000
committerDoug Barton <dougb@FreeBSD.org>2006-01-14 02:11:56 +0000
commit16cf7c033ff9fab106249a894e5670bd0b4fbbe8 (patch)
tree732644881f260d22d6298a820f529085aed4616d
parentb824835191139c577ca56bab6a86c7af4bd51c96 (diff)
downloadsrc-16cf7c033ff9fab106249a894e5670bd0b4fbbe8.tar.gz
src-16cf7c033ff9fab106249a894e5670bd0b4fbbe8.zip
Remove files from the vendor branch that are no longer present
in BIND 9.3.2 that were mistakenly removed from HEAD.
Notes
Notes: svn path=/vendor/bind9/dist/; revision=154334
-rw-r--r--contrib/bind9/bin/dnssec/dnssec-makekeyset.8113
-rw-r--r--contrib/bind9/bin/dnssec/dnssec-makekeyset.c401
-rw-r--r--contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook233
-rw-r--r--contrib/bind9/bin/dnssec/dnssec-makekeyset.html407
-rw-r--r--contrib/bind9/bin/dnssec/dnssec-signkey.8108
-rw-r--r--contrib/bind9/bin/dnssec/dnssec-signkey.c448
-rw-r--r--contrib/bind9/bin/dnssec/dnssec-signkey.docbook237
-rw-r--r--contrib/bind9/bin/dnssec/dnssec-signkey.html407
-rw-r--r--contrib/bind9/doc/arm/isc.color.gifbin6384 -> 0 bytes
-rw-r--r--contrib/bind9/doc/arm/nominum-docbook-html.dsl.in148
-rw-r--r--contrib/bind9/doc/arm/nominum-docbook-print.dsl.in42
-rw-r--r--contrib/bind9/doc/arm/validate.sh.in21
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt561
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt1457
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt3193
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt1849
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt639
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt335
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt1559
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt1235
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt466
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt1010
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt1120
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt1344
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt1321
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt1969
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt391
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt505
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt485
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt617
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt951
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
Binary files differ
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 co