mirror/freebsd
1
0
Fork 0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-18 10:35:55 +00:00
Code Issues Releases Activity

Remove files from the vendor branch that are no longer present

Browse Source 
in BIND 9.3.2 that were mistakenly removed from HEAD.
This commit is contained in:
Doug Barton 2006-01-14 02:11:56 +00:00
parent b824835191
commit 16cf7c033f
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/vendor/bind9/dist/; revision=154334
31 changed files with 0 additions and 23572 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

113
contrib/bind9/bin/dnssec/dnssec-makekeyset.8
View File

@ -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

401
contrib/bind9/bin/dnssec/dnssec-makekeyset.c
View File

@ -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);
}

233
contrib/bind9/bin/dnssec/dnssec-makekeyset.docbook
View File

@ -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:
-->

407
contrib/bind9/bin/dnssec/dnssec-makekeyset.html
View File

@ -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
>

108
contrib/bind9/bin/dnssec/dnssec-signkey.8
View File

@ -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

448
contrib/bind9/bin/dnssec/dnssec-signkey.c
View File

@ -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);
}

237
contrib/bind9/bin/dnssec/dnssec-signkey.docbook
View File

@ -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:
-->

407
contrib/bind9/bin/dnssec/dnssec-signkey.html
View File

@ -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
>

BIN
contrib/bind9/doc/arm/isc.color.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 6.2 KiB

148
contrib/bind9/doc/arm/nominum-docbook-html.dsl.in
View File

@ -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>

42
contrib/bind9/doc/arm/nominum-docbook-print.dsl.in
View File

@ -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>

21
contrib/bind9/doc/arm/validate.sh.in
View File

@ -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

561
contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
View File

@ -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]

1457
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
View File

File diff suppressed because it is too large Load Diff

3193
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
View File

File diff suppressed because it is too large Load Diff

1849
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
View File

File diff suppressed because it is too large Load Diff

639
contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt
View File

@ -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]

335
contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt
View File

@ -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]

1559
contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt
View File

File diff suppressed because it is too large Load Diff

1235
contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt
View File

File diff suppressed because it is too large Load Diff

466
contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
View File

@ -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]

1010
contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt
View File

File diff suppressed because it is too large Load Diff

1120
contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt
View File

File diff suppressed because it is too large Load Diff

1344
contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
View File

File diff suppressed because it is too large Load Diff

1321
contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
View File

File diff suppressed because it is too large Load Diff

1969
contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
View File

File diff suppressed because it is too large Load Diff

391
contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
View File

@ -1,391 +0,0 @@
DNSOP G. Guette
Internet-Draft IRISA / INRIA
Expires: February 5, 2005 O. Courtay
Thomson R&D
August 7, 2004
Requirements for Automated Key Rollover in DNSSEC
draft-ietf-dnsop-key-rollover-requirements-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 5, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes problems that appear during an automated
rollover and gives the requirements for the design of communication
between parent zone and child zone in an automated rollover process.
This document is essentially about key rollover, the rollover of
another Resource Record present at delegation point (NS RR) is also
discussed.
Guette & Courtay Expires February 5, 2005 [Page 1]
Internet-Draft Automated Rollover Requirements August 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
4. Messages authentication and information exchanged . . . . . . 4
5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
6. Other Resource Record concerned by automatic rollover . . . . 5
7. Security consideration . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7
Guette & Courtay Expires February 5, 2005 [Page 2]
Internet-Draft Automated Rollover Requirements August 2004
1. Introduction
The DNS security extensions (DNSSEC) [4][8][7][9] uses public-key
cryptography and digital signatures. It stores the public part of
keys in DNSKEY Resource Records (RRs). Because old keys and
frequently used keys are vulnerable, they must be renewed
periodically. In DNSSEC, this is the case for Zone Signing Keys
(ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key
rollover process is necessary for large zones because there are too
many changes to handle a manual administration.
Let us consider for example a zone with 100000 secure delegations.
If the child zones change their keys once a year on average, that
implies 300 changes per day for the parent zone. This amount of
changes are hard to manage manually.
Automated rollover is optional and resulting from an agreement
between the administrator of the parent zone and the administrator of
the child zone. Of course, key rollover can also be done manually by
administrators.
This document describes the requirements for the design of messages
of automated key rollover process and focusses on interaction between
parent and child zone.
2. The Key Rollover Process
Key rollover consists in renewing the DNSSEC keys used to sign
resource records in a given DNS zone file. There are two types of
rollover, ZSK rollovers and KSK rollovers.
In a ZSK rollover, all changes are local to the zone that renews its
key: there is no need to contact other zones (e.g., parent zone) to
propagate the performed changes because a ZSK has no associated DS
record in the parent zone.
In a KSK rollover, new DS RR(s) must be created and stored in the
parent zone. In consequence, the child zone must contact its parent
zone and must notify it about the KSK change(s).
Manual key rollover exists and works [3]. The key rollover is built
from two parts of different nature:
o An algorithm that generates new keys and signs the zone file. It
could be local to the zone
o The interaction between parent and child zones
One example of manual key rollover is:
Guette & Courtay Expires February 5, 2005 [Page 3]
Internet-Draft Automated Rollover Requirements August 2004
o The child zone creates a new KSK
o The child zone waits for the creation of the DS RR in its parent
zone
o The child zone deletes the old key.
In manual rollover, communications are managed by the zone
administrators and the security of these communications is out of
scope of DNSSEC.
Automated key rollover should use a secure communication between
parent and child zones. This document concentrates on defining
interactions between entities present in key rollover process.
3. Basic Requirements
The main constraint to respect during a key rollover is that the
chain of trust MUST be preserved, even if a resolver retrieves some
RRs from recursive cache server. Every RR MUST be verifiable at any
time, every RRs exchanged during the rollover should be authenticated
and their integrity should be guaranteed.
Two entities act during a KSK rollover: the child zone and its parent
zone. These zones are generally managed by different administrators.
These administrators should agree on some parameters like
availability of automated rollover, the maximum delay between
notification of changes in the child zone and the resigning of the
parent zone. The child zone needs to know this delay to schedule its
changes.
4. Messages authentication and information exchanged
Every exchanged message MUST be authenticated and the authentication
tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC
request with verifiable SIG records.
Once the changes related to a KSK are made in a child zone, this zone
MUST notify its parent zone in order to create the new DS RR and
store this DS RR in parent zone file.
The parent zone MUST receive all the child keys that needs the
creation of associated DS RRs in the parent zone.
Some errors could occur during transmission between child zone and
parent zone. Key rollover solution MUST be fault tolerant, i.e. at
any time the rollover MUST be in a consistent state and all RRs MUST
be verifiable, even if an error occurs. That is to say that it MUST
remain a valid chain of trust.
Guette & Courtay Expires February 5, 2005 [Page 4]
Internet-Draft Automated Rollover Requirements August 2004
5. Emergency Rollover
A key of a zone might be compromised and this key MUST be changed as
soon as possible. Fast changes could break the chain of trust. The
part of DNS tree having this zone as apex can become unverifiable,
but the break of the chain of trust is necessary if we want to no one
can use the compromised key to spoof DNS data.
In case of emergency rollover, the administrators of parent and child
zones should create new key(s) and DS RR(s) as fast as possible in
order to reduce the time the chain of trust is broken.
6. Other Resource Record concerned by automatic rollover
NS records are also present at delegation point, so when the child
zone renews some NS RR, the corresponding records at delegation point
in parent zone (glue) MUST be updated. NS records are concerned by
rollover and this rollover could be automated too. In this case,
when the child zone notifies its parent zone that some NS records
have been changed, the parent zone MUST verify that these NS records
are present in child zone before doing any changes in its own zone
file. This allows to avoid inconsistency between NS records at
delegation point and NS records present in the child zone.
7. Security consideration
This document describes requirements to design an automated key
rollover in DNSSEC based on DNSSEC security. In the same way, as
plain DNSSEC, the automatic key rollover contains no mechanism
protecting against denial of service (DoS). The security level
obtain after an automatic key rollover, is the security level
provided by DNSSEC.
8. Acknowledgments
The authors want to acknowledge Francis Dupont, Mohsen Souissi,
Bernard Cousin, Bertrand L‰onard and members of IDsA project for
their contribution to this document.
9 Normative References
[1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
RFC 3658, December 2003.
[2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
(DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
RFC 3757, May 2004.
Guette & Courtay Expires February 5, 2005 [Page 5]
Internet-Draft Automated Rollover Requirements August 2004
[3] Kolkman, O., "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practice-01 (work in
progress), May 2004.
[4] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[5] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[7] Arends, R., "Resource Records for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-09 (work in progress), July
2004.
[8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
"DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-11 (work in progress), July 2004.
[9] Arends, R., "Protocol Modifications for the DNS Security
Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in
progress), July 2004.
Authors' Addresses
Gilles Guette
IRISA / INRIA
Campus de Beaulieu
35042 Rennes CEDEX
FR
EMail: gilles.guette@irisa.fr
URI: http://www.irisa.fr
Olivier Courtay
Thomson R&D
1, avenue Belle Fontaine
35510 Cesson S‰vign‰ CEDEX
FR
EMail: olivier.courtay@thomson.net
Guette & Courtay Expires February 5, 2005 [Page 6]
Internet-Draft Automated Rollover Requirements August 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Guette & Courtay Expires February 5, 2005 [Page 7]

505
contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
View File

@ -1,505 +0,0 @@
IETF DNSOP Working Group Y. Morishita
Internet-Draft JPRS
Expires: July 11, 2004 T. Jinmei
Toshiba
January 11, 2004
Common Misbehavior against DNS Queries for IPv6 Addresses
draft-ietf-dnsop-misbehavior-against-aaaa-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 11, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
There is some known misbehavior of DNS authoritative servers when
they are queried for AAAA resource records. Such behavior can block
IPv4 communication which should actually be available, cause a
significant delay in name resolution, or even make a denial of
service attack. This memo describes details of the known cases and
discusses the effect of the cases.
1. Introduction
Many DNS clients (resolvers) that support IPv6 first search for AAAA
Resource Records (RRs) of a target host name, and then for A RRs of
Morishita & Jinmei Expires July 11, 2004 [Page 1]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
the same name. This fallback mechanism is based on the DNS
specifications, which if not obeyed by authoritative servers can
produce unpleasant results. In some cases, for example, a web browser
fails to connect to a web server it could otherwise. In the following
sections, this memo describes some typical cases of the misbehavior
and its (bad) effects.
Note that the misbehavior is not specific to AAAA RRs. In fact, all
known examples also apply to the cases of queries for MX, NS, and SOA
RRs. The authors even believe this can be generalized for all types
of queries other than those for A RRs. In this memo, however, we
concentrate on the case for AAAA queries, since the problem is
particularly severe for resolvers that support IPv6, which thus
affects many end users. Resolvers at end users normally send A and/or
AAAA queries only, and so the problem for the other cases is
relatively minor.
2. Network Model
In this memo, we assume a typical network model of name resolution
environment using DNS. It consists of three components; stub
resolvers, caching servers, and authoritative servers. A stub
resolver issues a recursive query to a caching server, which then
handles the entire name resolution procedure recursively. The caching
server caches the result of the query as well as sends the result to
the stub resolver. The authoritative servers respond to queries for
names for which they have the authority, normally in a non-recursive
manner.
3. Expected Behavior
Suppose that an authoritative server has an A RR but not a AAAA RR
for a host name. Then the server should return a response to a query
for a AAAA RR of the name with the RCODE being 0 (indicating no
error) and with an empty answer section [1]. Such a response
indicates that there is at least one RR of a different type than AAAA
for the queried name, and the stub resolver can then look for A RRs.
This way, the caching server can cache the fact that the queried name
does not have a AAAA RR (but may have other types of RRs), and thus
can improve the response time to further queries for a AAAA RR of the
name.
4. Problematic Behaviors
There are some known cases at authoritative servers that do not
conform to the expected behavior. This section describes those
problematic cases.
Morishita & Jinmei Expires July 11, 2004 [Page 2]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
4.1 Return NXDOMAIN
This type of server returns a response with the RCODE being 3
(NXDOMAIN) to a query for a AAAA RR, indicating it does not have any
RRs of any type for the queried name.
With this response, the stub resolver may immediately give up and
never fall back. Even if the resolver retries with a query for an A
RR, the negative response for the name has been cached in the caching
server, and the caching server will simply return the negative
response. As a result, the stub resolver considers this as a fatal
error in name resolution.
There have been several known examples of this behavior, but all the
examples that the authors know have changed their behavior as of this
writing.
4.2 Return NOTIMP
Other authoritative servers return a response with the RCODE being 4
(NOTIMP), indicating the servers do not support the requested type of
query.
This case is less harmful than the previous one; if the stub resolver
falls back to querying for an A RR, the caching server will process
the query correctly and return an appropriate response.
In this case, the caching server does not cache the fact that the
queried name has no AAAA RR, resulting in redundant queries for AAAA
RRs in the future. The behavior will waste network bandwidth and
increase the load of the authoritative server.
Using SERVFAIL or FORMERR would cause the same effect, though the
authors have not seen such implementations yet.
4.3 Return a Broken Response
Another different type of authoritative servers returns broken
responses to AAAA queries. A known behavior of this category is to
return a response whose RR type is AAAA, but the length of the RDATA
is 4 bytes. The 4-byte data looks like the IPv4 address of the
queried host name. That is, the RR in the answer section would be
described like this:
www.bad.example. 600 IN AAAA 192.0.2.1
which is, of course, bogus (or at least meaningless).
Morishita & Jinmei Expires July 11, 2004 [Page 3]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
A widely deployed caching server implementation transparently returns
the broken response (as well as caches it) to the stub resolver.
Another known server implementation parses the response by
themselves, and sends a separate response with the RCODE being 2
(SERVFAIL).
In either case, the broken response does not affect queries for an A
RR of the same name. If the stub resolver falls back to A queries, it
will get an appropriate response.
The latter case, however, causes the same bad effect as that
described in the previous section: redundant queries for AAAA RRs.
4.4 Make Lame Delegation
Some authoritative servers respond to AAAA queries in a way causing
lame delegation. In this case the parent zone specifies that the
authoritative server should have the authority of a zone, but the
server does not return an authoritative response for AAAA queries
within the zone (i.e., the AA bit in the response is not set). On the
other hand, the authoritative server returns an authoritative
response for A queries.
When a caching server asks the server for AAAA RRs in the zone, it
recognizes the delegation is lame, and return a response with the
RCODE being 2 (SERVFAIL) to the stub resolver.
Furthermore, some caching servers record the authoritative server as
lame for the zone and will not use it for a certain period of time.
With this type of caching server, even if the stub resolver falls
back to querying for an A RR, the caching server will simply return a
response with the RCODE being SERVFAIL, since all the servers are
known to be "lame."
There is also an implementation that relaxes the behavior a little
bit. It basically tries to avoid using the lame server, but still
continues to try it as a last resort. With this type of caching
server, the stub resolver will get a correct response if it falls
back after SERVFAIL. However, this still causes redundant AAAA
queries as explained in the previous sections.
4.5 Ignore Queries for AAAA
Some authoritative severs seem to ignore queries for a AAAA RR,
causing a delay at the stub resolver to fall back to a query for an A
RR. This behavior may even cause a fatal timeout at the resolver.
Morishita & Jinmei Expires July 11, 2004 [Page 4]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
5. Security Considerations
The CERT/CC pointed out that the response with NXDOMAIN described in
Section 4.1 can be used for a denial of service attack [2]. The same
argument applies to the case of "lame delegation" described in
Section 4.4 with a certain type of caching server.
6. Acknowledgements
Erik Nordmark encouraged the authors to publish this document as an
Internet Draft. Akira Kato and Paul Vixie reviewed a preliminary
version of this document. Pekka Savola carefully reviewed a previous
version and provided detailed comments.
Informative References
[1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
1034, November 1987.
[2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from
AAAA queries could cause denial-of-service conditions", March
2003, <http://www.kb.cert.org/vuls/id/714121>.
Authors' Addresses
MORISHITA Orange Yasuhiro
Research and Development Department, Japan Registry Service Co.,Ltd.
Fuundo Bldg 3F, 1-2 Kanda-Ogawamachi
Chiyoda-ku, Tokyo 101-0052
Japan
EMail: yasuhiro@jprs.co.jp
JINMEI Tatuya
Corporate Research & Development Center, Toshiba Corporation
1 Komukai Toshiba-cho, Saiwai-ku
Kawasaki-shi, Kanagawa 212-8582
Japan
EMail: jinmei@isl.rdc.toshiba.co.jp
Appendix A. Live Examples
In this appendix, we show concrete implementations and domain names
that may cause problematic cases so that the behavior can be
reproduced in a practical environment. The examples are for
Morishita & Jinmei Expires July 11, 2004 [Page 5]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
informational purposes only, and the authors do not intend to accuse
any implementations or zone administrators.
The behavior described in Section 4.2 (return NOTIMP) can be found by
looking for a AAAA RR of www.css.vtext.com at 66.174.3.4.
The behavior described in Section 4.3 (broken responses) can be seen
by querying for a AAAA RR of "www.gslb.mainichi.co.jp," which is an
alias of "www.mainichi.co.jp," at 210.173.172.2. The same behavior
can be found with the name "vip.alt.ihp.sony.co.jp," an alias of
"www.sony.co.jp," at 210.139.255.204.
The behavior described in Section 4.4 (lame delegation) can be found
by querying for a AAAA RR of "www.ual.com" at 209.87.113.4.
The behavior described in Section 4.5 (ignore queries) can be seen by
trying to ask for a AAAA RR of "ad.3jp.doubleclick.net," which is an
alias of "ad.jp.doubleclick.net," at 210.153.90.9.
Many authoritative server implementations show the expected behavior
described in Section 3. Some DNS load balancers reportedly have a
problematic behavior shown in Section 4, but the authors do not have
a concrete example. The CERT/CC provides a list of implementations
that behave as described in Section 4.1 [2].
The BIND9 caching server implementation is an example of the latter
cases described in Section 4.3 and Section 4.4, respectively. The
BIND8 caching server implementation is an example of the former case
described in Section 4.3. As for the issue shown in Section 4.4,
BIND8 caching servers prior to 8.3.5 show the behavior described as
the former case in this section. The versions 8.3.5 and later of
BIND8 caching server behave like the BIND9 caching server
implementation with this matter.
Regarding resolver implementations, the authors are only familiar
with the ones derived from the BIND implementation. These
implementations always fall back regardless of the RCODE; NXDOMAIN,
NOTIMP, or SERVFAIL. It even falls back when getting a broken
response. However, the behavior does not help the situation in the
NXDOMAIN case (see Section 4.1). Lame delegation (Section 4.4) also
causes a fatal error at the resolver side if the resolver is using
some older versions of BIND8 caching server.
The authors hear that a stub resolver routine implemented in some web
browsers interprets the broken response described in Section 4.3 as a
fatal error and does not fall back to A queries. However, we have not
confirmed this information.
Morishita & Jinmei Expires July 11, 2004 [Page 6]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
Appendix B. Change History
Changes since draft-morishita-dnsop-misbehavior-against-aaaa-00 are:
o Made a separate appendix and moved live examples to appendix so
that we can remove them when this document is (ever) officially
published.
o Revised some live examples based on the recent status.
o Noted in introduction that the misbehavior is not specific to AAAA
and that this document still concentrates on the AAAA case.
o Changed the section title of "delegation loop" to "lame
delegation" in order to reflect the essential point of the issue.
Wording on this matter was updated accordingly.
o Updated the Acknowledgements list.
o Changed the reference category from normative to informative (this
is an informational document after all).
o Changed the draft name to an IETF dnsop working group document (as
agreed).
o Applied several editorial fixes.
Morishita & Jinmei Expires July 11, 2004 [Page 7]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Morishita & Jinmei Expires July 11, 2004 [Page 8]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Morishita & Jinmei Expires July 11, 2004 [Page 9]

485
contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt
View File

@ -1,485 +0,0 @@
DNSOP Working Group Paul Vixie, ISC (Ed.)
INTERNET-DRAFT Akira Kato, WIDE
<draft-ietf-dnsop-respsize-01.txt> July, 2004
DNS Response Size Issues
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which we are aware have been or will be disclosed, and any of which
we become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003-2004). All Rights Reserved.
Abstract
With a mandated default minimum maximum message size of 512 octets,
the DNS protocol presents some special problems for zones wishing to
expose a moderate or high number of authority servers (NS RRs). This
document explains the operational issues caused by, or related to
this response size limit.
Expires December 2004 [Page 1]
INTERNET-DRAFT June 2003 RESPSIZE
1 - Introduction and Overview
1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
octets. Even though this limitation was due to the required minimum UDP
reassembly limit for IPv4, it is a hard DNS protocol limit and is not
implicitly relaxed by changes in transport, for example to IPv6.
1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
responses by mutual agreement of the requestor and responder. However,
deployment of EDNS0 cannot be expected to reach every Internet resolver
in the short or medium term. The 512 octet message size limit remains
in practical effect at this time.
1.3. Since DNS responses include a copy of the request, the space
available for response data is somewhat less than the full 512 octets.
For negative responses, there is rarely a space constraint. For
positive and delegation responses, though, every octet must be carefully
and sparingly allocated. This document specifically addresses
delegation response sizes.
2 - Delegation Details
2.1. A delegation response will include the following elements:
Header Section: fixed length (12 octets)
Question Section: original query (name, class, type)
Answer Section: (empty)
Authority Section: NS RRset (nameserver names)
Additional Section: A and AAAA RRsets (nameserver addresses)
2.2. If the total response size would exceed 512 octets, and if the data
that would not fit was in the question, answer, or authority section,
then the TC bit will be set (indicating truncation) which may cause the
requestor to retry using TCP, depending on what information was present
and what was omitted. If a retry using TCP is needed, the total cost of
the transaction is much higher.
2.3. RRsets are never sent partially, so if truncation occurs, entire
RRsets are omitted. Note that the authority section consists of a
single RRset. It is absolutely essential that truncation not occur in
the authority section.
Expires December 2004 [Page 2]
INTERNET-DRAFT June 2003 RESPSIZE
2.4. DNS label compression allows a domain name to be instantiated only
once per DNS message, and then referenced with a two-octet "pointer"
from other locations in that same DNS message. If all nameserver names
in a message are similar (for example, all ending in ".ROOT-
SERVERS.NET"), then more space will be available for uncompressable data
(such as nameserver addresses).
2.5. The query name can be as long as 255 characters of presentation
data, which can be up to 256 octets of network data. In this worst case
scenario, the question section will be 260 octets in size, which would
leave only 240 octets for the authority and additional sections (after
deducting 12 octets for the fixed length header.)
2.6. Average and maximum question section sizes can be predicted by the
zone owner, since they will know what names actually exist, and can
measure which ones are queried for most often. For cost and performance
reasons, the majority of requests should be satisfied without truncation
or TCP retry.
2.7. Requestors who deliberately send large queries to force truncation
are only increasing their own costs, and cannot effectively attack the
resources of an authority server since the requestor would have to retry
using TCP to complete the attack. An attack that always used TCP would
have a lower cost.
2.8. The minimum useful number of address records is two, since with
only one address, the probability that it would refer to an unreachable
server is too high. Truncation which occurs after two address records
have been added to the additional data section is therefore less
operationally significant than truncation which occurs earlier.
2.9. The best case is no truncation. (This is because many requestors
will retry using TCP by reflex, without considering whether the omitted
data was actually necessary.)
Expires December 2004 [Page 3]
INTERNET-DRAFT June 2003 RESPSIZE
3 - Analysis
3.1. An instrumented protocol trace of a best case delegation response
follows. Note that 13 servers are named, and 13 addresses are given.
This query was artificially designed to exactly reach the 512 octet
limit.
;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
;; QUERY SECTION:
;; [23456789.123456789.123456789.\
123456789.123456789.123456789.com A IN] ;; @80
;; AUTHORITY SECTION:
com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
;; MSG SIZE sent: 80 rcvd: 512
Expires December 2004 [Page 4]
INTERNET-DRAFT June 2003 RESPSIZE
3.2. For longer query names, the number of address records supplied will
be lower. Furthermore, it is only by using a common parent name (which
is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
fit. The following output from a response simulator demonstrates these
properties:
% perl respsize.pl 13 13 0
common name, average case: msg:303 nsaddr#13 (green)
common name, worst case: msg:495 nsaddr# 1 (red)
uncommon name, average case: msg:457 nsaddr# 3 (orange)
uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
% perl respsize.pl 13 13 2
common name, average case: msg:303 nsaddr#11 (orange)
common name, worst case: msg:495 nsaddr# 1 (red)
uncommon name, average case: msg:457 nsaddr# 2 (orange)
uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
(Note: The response simulator program is shown in Section 5.)
Here we use the term "green" if all address records could fit, or
"orange" if two or more could fit, or "red" if fewer than two could fit.
It's clear that without a common parent for nameserver names, much space
would be lost.
We're assuming an average query name size of 64 since that is the
typical average maximum size seen in trace data at the time of this
writing. If Internationalized Domain Name (IDN) or any other technology
which results in larger query names be deployed significantly in advance
of EDNS, then more new measurements and new estimates will have to be
made.
4 - Conclusions
4.1. The current practice of giving all nameserver names a common parent
(such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
responses and allows for more nameservers to be enumerated than would
otherwise be possible. (Note that in this case it is wise to serve the
common parent domain's zone from the same servers that are named within
it, in order to limit external dependencies when all your eggs are in a
single basket.)
4.2. Thirteen (13) seems to be the effective maximum number of
nameserver names usable traditional (non-extended) DNS, assuming a
common parent domain name, and assuming that additional-data truncation
is undesirable in the average case.
Expires December 2004 [Page 5]
INTERNET-DRAFT June 2003 RESPSIZE
4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
prototypical delegation that currently contains thirteen (13) IPv4
nameserver addresses (A RRs) for thirteen (13) nameserver names under a
common parent, would not have a significant negative operational impact
on the domain name system.
5 - Source Code
#!/usr/bin/perl -w
$asize = 2+2+2+4+2+4;
$aaaasize = 2+2+2+4+2+16;
($nns, $na, $naaaa) = @ARGV;
test("common", "average", common_name_average($nns),
$na, $naaaa);
test("common", "worst", common_name_worst($nns),
$na, $naaaa);
test("uncommon", "average", uncommon_name_average($nns),
$na, $naaaa);
test("uncommon", "worst", uncommon_name_worst($nns),
$na, $naaaa);
exit 0;
sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_;
my $nglue = numglue($msg, $na, $naaaa);
printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n",
$namekind, $casekind,
$msg, ($msg > 512) ? "(*)" : " ",
$nglue, ($nglue == $na + $naaaa) ? "green"
: ($nglue >= 2) ? "orange"
: "red";
}
sub pnum { my ($num, $tot) = @_;
return sprintf "%3d%s",
}
sub numglue { my ($msg, $na, $naaaa) = @_;
my $space = ($msg > 512) ? 0 : (512 - $msg);
my $num = 0;
while ($space && ($na || $naaaa )) {
if ($na) {
if ($space >= $asize) {
$space -= $asize;
Expires December 2004 [Page 6]
INTERNET-DRAFT June 2003 RESPSIZE
$num++;
}
$na--;
}
if ($naaaa) {
if ($space >= $aaaasize) {
$space -= $aaaasize;
$num++;
}
$naaaa--;
}
}
return $num;
}
sub msgsize { my ($qname, $nns, $nsns) = @_;
return 12 + # header
$qname+2+2 + # query
0 + # answer
$nns * (4+2+2+4+2+$nsns); # authority
}
sub average_case { my ($nns, $nsns) = @_;
return msgsize(64, $nns, $nsns);
}
sub worst_case { my ($nns, $nsns) = @_;
return msgsize(256, $nns, $nsns);
}
sub common_name_average { my ($nns) = @_;
return 15 + average_case($nns, 2);
}
sub common_name_worst { my ($nns) = @_;
return 15 + worst_case($nns, 2);
}
sub uncommon_name_average { my ($nns) = @_;
return average_case($nns, 15);
}
sub uncommon_name_worst { my ($nns) = @_;
return worst_case($nns, 15);
}
Expires December 2004 [Page 7]
INTERNET-DRAFT June 2003 RESPSIZE
Security Considerations
The recommendations contained in this document have no known security
implications.
IANA Considerations
This document does not call for changes or additions to any IANA
registry.
IPR Statement
Copyright (C) The Internet Society (2003-2004). This document is
subject to the rights, licenses and restrictions contained in BCP 78,
and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Authors' Addresses
Paul Vixie
950 Charter Street
Redwood City, CA 94063
+1 650 423 1301
vixie@isc.org
Akira Kato
University of Tokyo, Information Technology Center
2-11-16 Yayoi Bunkyo
Tokyo 113-8658, JAPAN
+81 3 5841 2750
kato@wide.ad.jp
Expires December 2004 [Page 8]

617
contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt
View File

@ -1,617 +0,0 @@
Network Working Group S. Woolf
Internet-Draft Internet Systems Consortium, Inc.
Expires: January 16, 2005 D. Conrad
Nominum, Inc.
July 18, 2004
Identifying an Authoritative Name `Server
draft-ietf-dnsop-serverid-02
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
With the increased use of DNS anycast, load balancing, and other
mechanisms allowing more than one DNS name server to share a single
IP address, it is sometimes difficult to tell which of a pool of name
servers has answered a particular query. A standardized mechanism to
determine the identity of a name server responding to a particular
query would be useful, particularly as a diagnostic aid. Existing ad
Woolf & Conrad Expires January 16, 2005 [Page 1]
Internet-Draft Identifying an Authoritative Name `Server July 2004
hoc mechanisms for addressing this concern are not adequate. This
document attempts to describe the common ad hoc solution to this
problem, including its advantages and disadvantasges, and to
characterize an improved mechanism.
Woolf & Conrad Expires January 16, 2005 [Page 2]
Internet-Draft Identifying an Authoritative Name `Server July 2004
1. Introduction
With the increased use of DNS anycast, load balancing, and other
mechanisms allowing more than one DNS name server to share a single
IP address, it is sometimes difficult to tell which of a pool of name
servers has answered a particular query. A standardized mechanism to
determine the identity of a name server responding to a particular
query would be useful, particularly as a diagnostic aid.
Unfortunately, existing ad-hoc mechanisms for providing such
identification have some shortcomings, not the least of which is the
lack of prior analysis of exactly how such a mechanism should be
designed and deployed. This document describes the existing
convention used in one widely deployed implementation of the DNS
protocol and discusses requirements for an improved solution to the
problem.
Woolf & Conrad Expires January 16, 2005 [Page 3]
Internet-Draft Identifying an Authoritative Name `Server July 2004
2. Rationale
Identifying which name server is responding to queries is often
useful, particularly in attempting to diagnose name server
difficulties. However, relying on the IP address of the name server
has become more problematic due the deployment of various load
balancing solutions, including the use of shared unicast addresses as
documented in [RFC3258].
An unfortunate side effect of these load balancing solutions is that
traditional methods of determining which server is responding can be
unreliable. Specifically, non-DNS methods such as ICMP ping, TCP
connections, or non-DNS UDP packets (e.g., as generated by tools such
as "traceroute"), etc., can end up going to a different server than
that which receives the DNS queries.
The widespread use of the existing convention suggests a need for a
documented, interoperable means of querying the identity of a
nameserver that may be part of an anycast or load-balancing cluster.
At the same time, however, it also has some drawbacks that argue
against standardizing it as it's been practiced so far.
Woolf & Conrad Expires January 16, 2005 [Page 4]
Internet-Draft Identifying an Authoritative Name `Server July 2004
3. Existing Conventions
Recent versions of the commonly deployed Berkeley Internet Name
Domain implementation of the DNS protocol suite from the Internet
Software Consortium [BIND] support a way of identifying a particular
server via the use of a standard, if somewhat unusual, DNS query.
Specifically, a query to a late model BIND server for a TXT resource
record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
return a string that can be configured by the name server
administrator to provide a unique identifier for the responding
server (defaulting to the value of a gethostname() call). This
mechanism, which is an extension of the BIND convention of using
CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
version information, has been copied by several name server vendors.
For reference, the other well-known name used by recent versions of
BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
query for a TXT RR for this name will return an administratively re-
definable string which defaults to the version of the server
responding.
3.1 Advantages
There are several valuable attributes to this mechanism, which
account for its usefulness.
1. This mechanism is within the DNS protocol itself. An
identification mechanism that relies on the DNS protocol is more
likely to be successful (although not guaranteed) in going to the
same machine as a "normal" DNS query.
2. It is simple to configure. An administrator can easily turn on
this feature and control the results of the relevant query.
3. It allows the administrator complete control of what information
is given out in the response, minimizing passive leakage of
implementation or configuration details. Such details are often
considered sensitive by infrastructure operators.
3.2 Disadvantages
At the same time, there are some forbidding drawbacks to the
VERSION.BIND mechanism that argue against standardizing it as it
currently operates.
1. It requires an additional query to correlate between the answer
to a DNS query under normal conditions and the supposed identity
of the server receiving the query. There are a number of
situations in which this simply isn't reliable.
2. It reserves an entire class in the DNS (CHAOS) for what amounts
to one zone. While CHAOS class is defined in [RFC1034] and
[RFC1035], it's not clear that supporting it solely for this
Woolf & Conrad Expires January 16, 2005 [Page 5]
Internet-Draft Identifying an Authoritative Name `Server July 2004
purpose is a good use of the namespace or of implementation
effort.
3. It is implementation specific. BIND is one DNS implementation.
At the time of this writing, it is probably the most prevalent,
for authoritative servers anyway. This does not justify
standardizing on its ad hoc solution to a problem shared across
many operators and implementors.
The first of the listed disadvantages is technically the most
serious. It argues for an attempt to design a good answer to the
problem that "I need to know what nameserver is answering my
queries", not simply a convenient one.
Woolf & Conrad Expires January 16, 2005 [Page 6]
Internet-Draft Identifying an Authoritative Name `Server July 2004
4. Characteristics of an Implementation Neutral Convention
The discussion above of advantages and disadvantages to the
HOSTNAME.BIND mechanism suggest some requirements for a better
solution to the server identification problem. These are summarized
here as guidelines for any effort to provide appropriate protocol
extensions:
1. The mechanism adopted MUST be in-band for the DNS protocol. That
is, it needs to allow the query for the server's identifying
information to be part of a normal, operational query. It SHOULD
also permit a separate, dedicated query for the server's
identifying information.
2. The new mechanism should not require dedicated namespaces or
other reserved values outside of the existing protocol mechanisms
for these, i.e. the OPT pseudo-RR.
3. Support for the identification functionality SHOULD be easy to
implement and easy to enable. It MUST be easy to disable and
SHOULD lend itself to access controls on who can query for it.
4. It should be possible to return a unique identifier for a server
without requiring the exposure of information that may be
non-public and considered sensitive by the operator, such as a
hostname or unicast IP address maintained for administrative
purposes.
5. The identification mechanism SHOULD NOT be
implementation-specific.
Woolf & Conrad Expires January 16, 2005 [Page 7]
Internet-Draft Identifying an Authoritative Name `Server July 2004
5. IANA Considerations
This document proposes no specific IANA action. Protocol extensions,
if any, to meet the requirements described are out of scope for this
document. Should such extensions be specified and adopted by normal
IETF process, the specification will include appropriate guidance to
IANA.
Woolf & Conrad Expires January 16, 2005 [Page 8]
Internet-Draft Identifying an Authoritative Name `Server July 2004
6. Security Considerations
Providing identifying information as to which server is responding
can be seen as information leakage and thus a security risk. This
motivates the suggestion above that a new mechanism for server
identification allow the administrator to disable the functionality
altogether or partially restrict availability of the data. It also
suggests that the serverid data should not be readily correlated with
a hostname or unicast IP address that may be considered private to
the nameserver operator's management infrastructure.
Propagation of protocol or service meta-data can sometimes expose the
application to denial of service or other attack. As DNS is a
critically important infrastructure service for the production
Internet, extra care needs to be taken against this risk for
designers, implementors, and operators of a new mechanism for server
identification.
Woolf & Conrad Expires January 16, 2005 [Page 9]
Internet-Draft Identifying an Authoritative Name `Server July 2004
7. Acknowledgements
The technique for host identification documented here was initially
implemented by Paul Vixie of the Internet Software Consortium in the
Berkeley Internet Name Daemon package. Comments and questions on
earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
ICANN Root Server System Advisory Committee. The newest draft takes
a significantly different direction from previous versions, owing to
discussion among contributors to the DNSOP working group and others,
particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler,
and Rob Austein.
Woolf & Conrad Expires January 16, 2005 [Page 10]
Internet-Draft Identifying an Authoritative Name `Server July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Woolf & Conrad Expires January 16, 2005 [Page 11]

951
contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt
View File

@ -1,951 +0,0 @@
IPSECKEY WG M. Richardson
Internet-Draft SSW
|Expires: August 1, 2004 February 2004
A Method for Storing IPsec Keying Material in DNS
| draft-ietf-ipseckey-rr-09.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
| This Internet-Draft will expire on August 1, 2004.
Copyright Notice
| Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
| This document describes a new resource record for Domain Name System
| (DNS). This record may be used to store public keys for use in IP
| security (IPsec) systems. The record also includes provisions for
| indicating what system should be contacted when establishing an IPsec
| tunnel with the entity in question.
This record replaces the functionality of the sub-type #1 of the KEY
Resource Record, which has been obsoleted by RFC3445.
|Richardson Expires August 1, 2004 [Page 1]
|Internet-Draft Storing IPsec keying material in DNS February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
| 1.2 Use of reverse (in-addr.arpa) map . . . . . . . . . . . . . . 3
| 1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3
| 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 5
| 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5
| 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5
| 2.3 RDATA format - gateway type . . . . . . . . . . . . . . . . . 5
| 2.4 RDATA format - algorithm type . . . . . . . . . . . . . . . . 6
| 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6
| 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 6
| 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 8
| 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 8
| 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
| 4.1 Active attacks against unsecured IPSECKEY resource records . . 10
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
| 6. Intellectual Property Claims . . . . . . . . . . . . . . . . . 13
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
| Normative references . . . . . . . . . . . . . . . . . . . . . 15
| Non-normative references . . . . . . . . . . . . . . . . . . . 16
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
| Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
|Richardson Expires August 1, 2004 [Page 2]
|Internet-Draft Storing IPsec keying material in DNS February 2004
1. Introduction
It postulated that there is an end system desiring to establish an
IPsec tunnel with some remote entity on the network. This system,
having only a DNS name of some kind (forward, reverse or even
user@FQDN) needs a public key to authenticate the remote entity. It
also desires some guidance about whether to contact the entity
directly, or whether to contact another entity, as the gateway to
that desired entity.
The IPSECKEY RR provides a storage mechanism for such items as the
public key, and the gateway information.
The type number for the IPSECKEY RR is TBD.
1.1 Overview
The IPSECKEY resource record (RR) is used to publish a public key
that is to be associated with a Domain Name System (DNS) name for use
with the IPsec protocol suite. This can be the public key of a
host, network, or application (in the case of per-port keying).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [7].
|1.2 Use of reverse (in-addr.arpa) map
| Often a security gateway will only have access to the IP address to
| which communication is desired. It will not know the forward name.
| As such, it will frequently be the case that the IP address will be
| used an index into the reverse map.
| The lookup is done in the usual fashion as for PTR records. The IP
| address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
| under the .arpa. zone. Any CNAMEs or DNAMEs found SHOULD be
| followed.
| Note: even when the IPsec function is the end-host, often only the
| application will know the forward name used. While the case where
| the application knows the forward name is common, the user could
| easily have typed in a literal IP address. This storage mechanism
| does not preclude using the forward name when it is available, but
| does not require it.
|1.3 Usage Criteria
An IPSECKEY resource record SHOULD be used in combination with DNSSEC
|Richardson Expires August 1, 2004 [Page 3]
|Internet-Draft Storing IPsec keying material in DNS February 2004
unless some other means of authenticating the IPSECKEY resource
record is available.
It is expected that there will often be multiple IPSECKEY resource
records at the same name. This will be due to the presence of
multiple gateways and the need to rollover keys.
This resource record is class independent.
|Richardson Expires August 1, 2004 [Page 4]
|Internet-Draft Storing IPsec keying material in DNS February 2004
2. Storage formats
2.1 IPSECKEY RDATA format
The RDATA for an IPSECKEY RR consists of a precedence value, a
gateway type, a public key, algorithm type, and an optional gateway
address.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence | gateway type | algorithm | gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ +
~ gateway ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
2.2 RDATA format - precedence
This is an 8-bit precedence for this record. This is interpreted in
the same way as the PREFERENCE field described in section 3.3.9 of
RFC1035 [2].
Gateways listed in IPSECKEY records with lower precedence are to be
attempted first. Where there is a tie in precedence, the order
should be non-deterministic.
2.3 RDATA format - gateway type
The gateway type field indicates the format of the information that
is stored in the gateway field.
The following values are defined:
0 No gateway is present
1 A 4-byte IPv4 address is present
2 A 16-byte IPv6 address is present
3 A wire-encoded domain name is present. The wire-encoded format is
self-describing, so the length is implicit. The domain name MUST
NOT be compressed. (see section 3.3 of RFC1035 [2]).
|Richardson Expires August 1, 2004 [Page 5]
|Internet-Draft Storing IPsec keying material in DNS February 2004
2.4 RDATA format - algorithm type
The algorithm type field identifies the public key's cryptographic
algorithm and determines the format of the public key field.
A value of 0 indicates that no key is present.
The following values are defined:
1 A DSA key is present, in the format defined in RFC2536 [10]
2 A RSA key is present, in the format defined in RFC3110 [11]
2.5 RDATA format - gateway
The gateway field indicates a gateway to which an IPsec tunnel may be
created in order to reach the entity named by this resource record.
There are three formats:
A 32-bit IPv4 address is present in the gateway field. The data
portion is an IPv4 address as described in section 3.4.1 of RFC1035
[2]. This is a 32-bit number in network byte order.
A 128-bit IPv6 address is present in the gateway field. The data
portion is an IPv6 address as described in section 2.2 of RFC3596
[13]. This is a 128-bit number in network byte order.
The gateway field is a normal wire-encoded domain name, as described
in section 3.3 of RFC1035 [2]. Compression MUST NOT be used.
2.6 RDATA format - public keys
Both of the public key types defined in this document (RSA and DSA)
inherit their public key formats from the corresponding KEY RR
formats. Specifically, the public key field contains the algorithm-
specific portion of the KEY RR RDATA, which is all of the KEY RR DATA
after the first four octets. This is the same portion of the KEY RR
that must be specified by documents that define a DNSSEC algorithm.
Those documents also specify a message digest to be used for
generation of SIG RRs; that specification is not relevant for
IPSECKEY RR.
Future algorithms, if they are to be used by both DNSSEC (in the KEY
RR) and IPSECKEY, are likely to use the same public key encodings in
both records. Unless otherwise specified, the IPSECKEY public key
field will contain the algorithm-specific portion of the KEY RR RDATA
|Richardson Expires August 1, 2004 [Page 6]
|Internet-Draft Storing IPsec keying material in DNS February 2004
for the corresponding algorithm. The algorithm must still be
designated for use by IPSECKEY, and an IPSECKEY algorithm type number
(which might be different than the DNSSEC algorithm number) must be
assigned to it.
The DSA key format is defined in RFC2536 [10]
The RSA key format is defined in RFC3110 [11], with the following
changes:
The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
modulus to 2552 bits in length. RFC3110 extended that limit to 4096
bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on
RSA public keys, other than the 65535 octet limit imposed by the two-
octet length encoding. This length extension is applicable only to
IPSECKEY and not to KEY RRs.
|Richardson Expires August 1, 2004 [Page 7]
|Internet-Draft Storing IPsec keying material in DNS February 2004
3. Presentation formats
3.1 Representation of IPSECKEY RRs
IPSECKEY RRs may appear in a zone data master file. The precedence,
gateway type and algorithm and gateway fields are REQUIRED. The
base64 encoded public key block is OPTIONAL; if not present, then the
public key field of the resource record MUST be construed as being
zero octets in length.
The algorithm field is an unsigned integer. No mnemonics are
defined.
If no gateway is to be indicated, then the gateway type field MUST be
zero, and the gateway field MUST be "."
The Public Key field is represented as a Base64 encoding of the
Public Key. Whitespace is allowed within the Base64 text. For a
definition of Base64 encoding, see RFC3548 [6] Section 5.2.
The general presentation for the record as as follows:
IN IPSECKEY ( precedence gateway-type algorithm
gateway base64-encoded-public-key )
3.2 Examples
An example of a node 192.0.2.38 that will accept IPsec tunnels on its
own behalf.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
192.0.2.38
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 192.0.2.38 that has published its key only.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2
.
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 192.0.2.38 that has delegated authority to the
node 192.0.2.3.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
192.0.2.3
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
|Richardson Expires August 1, 2004 [Page 8]
|Internet-Draft Storing IPsec keying material in DNS February 2004
An example of a node, 192.0.1.38 that has delegated authority to the
node with the identity "mygateway.example.com".
38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2
mygateway.example.com.
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has
delegated authority to the node 2001:0DB8:c000:0200:2::1
$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2
2001:0DB8:0:8002::2000:1
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
|Richardson Expires August 1, 2004 [Page 9]
|Internet-Draft Storing IPsec keying material in DNS February 2004
4. Security Considerations
This entire memo pertains to the provision of public keying material
for use by key management protocols such as ISAKMP/IKE (RFC2407) [8].
The IPSECKEY resource record contains information that SHOULD be
communicated to the end client in an integral fashion - i.e. free
from modification. The form of this channel is up to the consumer of
the data - there must be a trust relationship between the end
consumer of this resource record and the server. This relationship
may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
another secure source, a secure local channel on the host, or some
combination of the above.
The keying material provided by the IPSECKEY resource record is not
sensitive to passive attacks. The keying material may be freely
disclosed to any party without any impact on the security properties
of the resulting IPsec session: IPsec and IKE provide for defense
against both active and passive attacks.
Any derivative standard that makes use of this resource record MUST
carefully document their trust model, and why the trust model of
DNSSEC is appropriate, if that is the secure channel used.
4.1 Active attacks against unsecured IPSECKEY resource records
This section deals with active attacks against the DNS. These
attacks require that DNS requests and responses be intercepted and
changed. DNSSEC is designed to defend against attacks of this kind.
The first kind of active attack is when the attacker replaces the
keying material with either a key under its control or with garbage.
If the attacker is not able to mount a subsequent man-in-the-middle
attack on the IKE negotiation after replacing the public key, then
this will result in a denial of service, as the authenticator used by
IKE would fail.
If the attacker is able to both to mount active attacks against DNS
and is also in a position to perform a man-in-the-middle attack on
IKE and IPsec negotiations, then the attacker will be in a position
to compromise the resulting IPsec channel. Note that an attacker
must be able to perform active DNS attacks on both sides of the IKE
negotiation in order for this to succeed.
The second kind of active attack is one in which the attacker
replaces the the gateway address to point to a node under the
attacker's control. The attacker can then either replace the public
|Richardson Expires August 1, 2004 [Page 10]
|Internet-Draft Storing IPsec keying material in DNS February 2004
key or remove it, thus providing an IPSECKEY record of its own to
match the gateway address.
This later form creates a simple man-in-the-middle since the attacker
can then create a second tunnel to the real destination. Note that,
as before, this requires that the attacker also mount an active
attack against the responder.
Note that the man-in-the-middle can not just forward cleartext
packets to the original destination. While the destination may be
willing to speak in the clear, replying to the original sender, the
sender will have already created a policy expecting ciphertext.
Thus, the attacker will need to intercept traffic from both sides.
In some cases, the attacker may be able to accomplish the full
intercept by use of Network Addresss/Port Translation (NAT/NAPT)
technology.
| Note that risk of a man-in-the-middle attack mediated by the IPSECKEY
| RR only applies to cases where the gateway field of the IPSECKEY RR
| indicates a different entity than the owner name of the IPSECKEY RR.
| An active attack on the DNS that caused the wrong IP address to be
| retrieved (via forged A RR), and therefore the wrong QNAME to be
| queried would also result in a man-in-the-middle attack. This
| situation exists independantly of whether or not the IPSECKEY RR is
| used.
| In cases where the end-to-end integrity of the IPSECKEY RR is
| suspect, the end client MUST restrict its use of the IPSECKEY RR to
| cases where the RR owner name matches the content of the gateway
| field.
|Richardson Expires August 1, 2004 [Page 11]
|Internet-Draft Storing IPsec keying material in DNS February 2004
5. IANA Considerations
This document updates the IANA Registry for DNS Resource Record Types
by assigning type X to the IPSECKEY record.
This document creates two new IANA registries, both specific to the
IPSECKEY Resource Record:
This document creates an IANA registry for the algorithm type field.
Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3
through 255 can be assigned by IETF Consensus (see RFC2434 [5]).
This document creates an IANA registry for the gateway type field.
Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type
numbers 4 through 255 can be assigned by Standards Action (see
RFC2434 [5]).
|Richardson Expires August 1, 2004 [Page 12]
|Internet-Draft Storing IPsec keying material in DNS February 2004
6. Intellectual Property Claims
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
|Richardson Expires August 1, 2004 [Page 13]
|Internet-Draft Storing IPsec keying material in DNS February 2004
7. Acknowledgments
My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
Austein, and Olafur Gurmundsson who reviewed this document carefully.
Additional thanks to Olafur Gurmundsson for a reference
implementation.
|Richardson Expires August 1, 2004 [Page 14]
|Internet-Draft Storing IPsec keying material in DNS February 2004
Normative references
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[4] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
|Richardson Expires August 1, 2004 [Page 15]
|Internet-Draft Storing IPsec keying material in DNS February 2004
Non-normative references
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[9] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)", RFC 3110, May 2001.
[12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.
[13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
Extensions to Support IP Version 6", RFC 3596, October 2003.
Author's Address
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z 5V7
CA
EMail: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/
|Richardson Expires August 1, 2004 [Page 16]
|Internet-Draft Storing IPsec keying material in DNS February 2004
Full Copyright Statement
| Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
|Richardson Expires August 1, 2004 [Page 17]