diff options
103 files changed, 11853 insertions, 11286 deletions
@@ -1,4 +1,67 @@ + --- 9.3.0rc1 released --- + +1664. [bug] nsupdate needed KEY for SIG(0), not DNSKEY. + +1662. [bug] Change #1658 failed to change one use of 'type' + to 'keytype'. + +1659. [cleanup] Cleanup some messages that were referring to KEY vs + DNSKEY, NXT vs NSEC and SIG vs RRSIG. + +1658. [func] Update dnssec-keygen to default to KEY for HMAC-MD5 + and DH. Tighten which options apply to KEY and + DNSKEY records. + +1657. [doc] ARM: document query log output. + +1656. [doc] Update DNSSEC description in ARM to cover DS, NSEC + DNSKEY and RRSIG. [RT #11542] + +1655. [bug] Logging multiple versions w/o a size was broken. + [RT #11446] + +1654. [bug] isc_result_totext() contained array bounds read + error. + +1653. [func] Add key type checking to dst_key_fromfilename(), + DST_TYPE_KEY should be used to read TSIG, TKEY and + SIG(0) keys. + +1652. [bug] TKEY still uses KEY. + +1651. [bug] dig: process multiple dash options. + +1650. [bug] dig, nslookup: flush standard out after each command. + +1649. [bug] Silence "unexpected non-minimal diff" message. + [RT #11206] + +1648. [func] Update dnssec-lookaside named.conf syntax to support + multiple dnssec-lookaside namespaces (not yet + implemented). + +1647. [bug] It was possible trigger a INSIST when chasing a DS + record that required walking back over a empty node. + [RT #11445] + +1646. [bug] win32: logging file versions didn't work with + non-UNC filenames. [RT#11486] + +1645. [bug] named could trigger a REQUIRE failure if multiple + masters with keys are specified. + +1644. [bug] Update the journal modification time after a + sucessfull refresh query. [RT #11436] + +1643. [bug] dns_db_closeversion() could leak memory / node + references. [RT #11163] + +1642. [port] Support OpenSSL implementations which don't have + DSA support. [RT #11360] + +1641. [bug] Update the check-names description in ARM. [RT #11389] + --- 9.3.0beta4 released --- 1640. [bug] win32: isc_socket_cancel(ISC_SOCKCANCEL_ACCEPT) was @@ -415,3 +415,35 @@ information in the chroot area. OSF: /etc/zoneinfo/localtime See also tzset(3) and zic(8). + + +Q: I get the error message "named: capset failed: Operation not permitted" +when starting named. + +A: The capset module has not been loaded into the kernel. See insmod(8). + + +Q: I get "rndc: connect failed: connection refused" when I try to run + rndc. + +A: This is usually a configuration error. + + First ensure that named is running and no errors are being + reported at startup (/var/log/messages or equivalent). Running + "named -g <usual arguements>" from a terminal can help at this + point. + + Secondly ensure that named is configured to use rndc either by + "rndc-confgen -a", rndc-confgen or manually. The Administators + Reference manual has details on how to do this. + + Old versions of rndc-confgen used localhost rather than 127.0.0.1 + in /etc/rndc.conf for the default server. Update /etc/rndc.conf + if necessary so that the default server listed in /etc/rndc.conf + matches the addresses used in named.conf. "localhost" has two + address (127.0.0.1 and ::1). + + If you use "rndc-confgen -a" and named is running with -t or -u + ensure that /etc/rndc.conf has the correct ownership and that + a copy is in the chroot area. You can do this by re-running + "rndc-confgen -a" with appropriate -t and -u arguements. @@ -327,9 +327,9 @@ Bug Reports and Mailing Lists bind9-bugs@isc.org - To join the BIND 9 Users mailing list, send mail to + To join the BIND Users mailing list, send mail to - bind9-users-request@isc.org + bind-users-request@isc.org archives of which can be found via @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: acconfig.h,v 1.35.2.4.2.7 2004/03/08 04:04:12 marka Exp $ */ +/* $Id: acconfig.h,v 1.35.2.4.2.8 2004/05/21 08:24:04 marka Exp $ */ /*** *** This file is not to be included by any public header files, because @@ -136,3 +136,6 @@ int sigwait(const unsigned int *set, int *sig); /* Define if you are running under Compaq TruCluster.. */ #undef HAVE_TRUCLUSTER + +/* Define if OpenSSL includes DSA support */ +#undef HAVE_OPENSSL_DSA diff --git a/bin/check/named-checkconf.8 b/bin/check/named-checkconf.8 index 1166de90..25dbdd86 100644 --- a/bin/check/named-checkconf.8 +++ b/bin/check/named-checkconf.8 @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: named-checkconf.8,v 1.11.12.3 2004/03/08 04:04:13 marka Exp $ +.\" $Id: named-checkconf.8,v 1.11.12.4 2004/06/03 05:35:41 marka Exp $ .\" .TH "NAMED-CHECKCONF" "8" "June 14, 2000" "BIND9" "" .SH NAME @@ -56,4 +56,4 @@ errors were detected and 0 otherwise. \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/bin/check/named-checkconf.docbook b/bin/check/named-checkconf.docbook index 468f9269..d1336cfa 100644 --- a/bin/check/named-checkconf.docbook +++ b/bin/check/named-checkconf.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: named-checkconf.docbook,v 1.3.2.1.8.4 2004/03/08 04:04:13 marka Exp $ --> +<!-- $Id: named-checkconf.docbook,v 1.3.2.1.8.5 2004/06/03 02:24:59 marka Exp $ --> <refentry> <refentryinfo> @@ -132,7 +132,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/check/named-checkconf.html b/bin/check/named-checkconf.html index f4de0b29..4d9e68da 100644 --- a/bin/check/named-checkconf.html +++ b/bin/check/named-checkconf.html @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: named-checkconf.html,v 1.5.2.1.4.3 2004/03/08 04:04:13 marka Exp $ --> +<!-- $Id: named-checkconf.html,v 1.5.2.1.4.4 2004/06/03 05:35:42 marka Exp $ --> <HTML ><HEAD @@ -212,7 +212,7 @@ NAME="AEN69" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/bin/check/named-checkzone.8 b/bin/check/named-checkzone.8 index bdf2e14f..efa600c8 100644 --- a/bin/check/named-checkzone.8 +++ b/bin/check/named-checkzone.8 @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: named-checkzone.8,v 1.11.2.1.8.3 2004/03/08 04:04:14 marka Exp $ +.\" $Id: named-checkzone.8,v 1.11.2.1.8.4 2004/06/03 05:35:42 marka Exp $ .\" .TH "NAMED-CHECKZONE" "8" "June 13, 2000" "BIND9" "" .SH NAME @@ -91,4 +91,4 @@ errors were detected and 0 otherwise. \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/bin/check/named-checkzone.docbook b/bin/check/named-checkzone.docbook index a31612cf..68b0baee 100644 --- a/bin/check/named-checkzone.docbook +++ b/bin/check/named-checkzone.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: named-checkzone.docbook,v 1.3.2.2.8.6 2004/03/08 04:04:14 marka Exp $ --> +<!-- $Id: named-checkzone.docbook,v 1.3.2.2.8.7 2004/06/03 02:25:00 marka Exp $ --> <refentry> <refentryinfo> @@ -222,7 +222,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/check/named-checkzone.html b/bin/check/named-checkzone.html index 5939050e..bd2fa1e4 100644 --- a/bin/check/named-checkzone.html +++ b/bin/check/named-checkzone.html @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: named-checkzone.html,v 1.5.2.2.4.3 2004/03/08 04:04:14 marka Exp $ --> +<!-- $Id: named-checkzone.html,v 1.5.2.2.4.4 2004/06/03 05:35:43 marka Exp $ --> <HTML ><HEAD @@ -383,7 +383,7 @@ NAME="AEN137" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/bin/dig/dig.c b/bin/dig/dig.c index b8bfcc26..f91a2889 100644 --- a/bin/dig/dig.c +++ b/bin/dig/dig.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dig.c,v 1.157.2.13.2.16 2004/04/15 06:49:09 marka Exp $ */ +/* $Id: dig.c,v 1.157.2.13.2.18 2004/06/07 03:56:25 marka Exp $ */ #include <config.h> #include <stdlib.h> @@ -144,8 +144,8 @@ static void print_usage(FILE *fp) { fputs( "Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}\n" -" {global-d-opt} host [@local-server] {local-d-opt}\n" -" [ host [@local-server] {local-d-opt} [...]]\n", fp); +" {global-d-opt} host [@local-server] {local-d-opt}\n" +" [ host [@local-server] {local-d-opt} [...]]\n", fp); } static void @@ -165,7 +165,7 @@ static void help(void) { print_usage(stdout); fputs( -"Where: domain are in the Domain Name System\n" +"Where: domain is in the Domain Name System\n" " q-class is one of (in,hs,ch,...) [default: in]\n" " q-type is one of (a,any,mx,ns,soa,hinfo,axfr,txt,...) [default:a]\n" " (Use ixfr=version for type ixfr)\n" @@ -173,7 +173,7 @@ help(void) { " -x dot-notation (shortcut for in-addr lookups)\n" " -i (IP6.INT reverse IPv6 lookups)\n" " -f filename (batch mode)\n" -" -b address (bind to source address)\n" +" -b address[#port] (bind to source address/port)\n" " -p port (specify port number)\n" " -t type (specify query type)\n" " -c class (specify query class)\n" @@ -1073,13 +1073,14 @@ plus_option(char *option, isc_boolean_t is_batchfile, /* * ISC_TRUE returned if value was used */ +static const char *single_dash_opts = "46dhimnv"; +static const char *dash_opts = "46bcdfhikmnptvyx"; static isc_boolean_t dash_option(char *option, char *next, dig_lookup_t **lookup, - isc_boolean_t *open_type_class, - isc_boolean_t *firstarg, - int argc, char **argv) + isc_boolean_t *open_type_class, isc_boolean_t *firstarg, + int argc, char **argv) { - char cmd, *value, *ptr; + char opt, *value, *ptr; isc_result_t result; isc_boolean_t value_from_next; isc_textregion_t tr; @@ -1089,9 +1090,68 @@ dash_option(char *option, char *next, dig_lookup_t **lookup, struct in_addr in4; struct in6_addr in6; in_port_t srcport; - char *hash; + char *hash, *cmd; - cmd = option[0]; + while (strpbrk(option, single_dash_opts) == &option[0]) { + /* + * Since the -[46dhimnv] options do not take an argument, + * account for them (in any number and/or combination) + * if they appear as the first character(s) of a q-opt. + */ + opt = option[0]; + switch (opt) { + case '4': + if (have_ipv4) { + isc_net_disableipv6(); + have_ipv6 = ISC_FALSE; + } else { + fatal("can't find IPv4 networking"); + return (ISC_FALSE); + } + break; + case '6': + if (have_ipv6) { + isc_net_disableipv4(); + have_ipv4 = ISC_FALSE; + } else { + fatal("can't find IPv6 networking"); + return (ISC_FALSE); + } + break; + case 'd': + ptr = strpbrk(&option[1], dash_opts); + if (ptr != &option[1]) { + cmd = option; + FULLCHECK("debug"); + debugging = ISC_TRUE; + return (ISC_FALSE); + } else + debugging = ISC_TRUE; + break; + case 'h': + help(); + exit(0); + break; + case 'i': + ip6_int = ISC_TRUE; + break; + case 'm': /* memdebug */ + /* memdebug is handled in preparse_args() */ + break; + case 'n': + /* deprecated */ + break; + case 'v': + version(); + exit(0); + break; + } + if (strlen(option) > 1U) + option = &option[1]; + else + return (ISC_FALSE); + } + opt = option[0]; if (strlen(option) > 1U) { value_from_next = ISC_FALSE; value = &option[1]; @@ -1099,45 +1159,9 @@ dash_option(char *option, char *next, dig_lookup_t **lookup, value_from_next = ISC_TRUE; value = next; } - switch (cmd) { - case 'd': - debugging = ISC_TRUE; - return (ISC_FALSE); - case 'h': - help(); - exit(0); - break; - case 'i': - ip6_int = ISC_TRUE; - return (ISC_FALSE); - case 'm': /* memdebug */ - /* memdebug is handled in preparse_args() */ - return (ISC_FALSE); - case 'n': - /* deprecated */ - return (ISC_FALSE); - case '4': - if (have_ipv4) { - isc_net_disableipv6(); - have_ipv6 = ISC_FALSE; - } else - fatal("can't find IPv4 networking"); - return (ISC_FALSE); - case '6': - if (have_ipv6) { - isc_net_disableipv4(); - have_ipv4 = ISC_FALSE; - } else - fatal("can't find IPv6 networking"); - return (ISC_FALSE); - case 'v': - version(); - exit(0); - break; - } if (value == NULL) goto invalid_option; - switch (cmd) { + switch (opt) { case 'b': hash = strchr(value, '#'); if (hash != NULL) { @@ -1289,20 +1313,26 @@ static void preparse_args(int argc, char **argv) { int rc; char **rv; + char *option; rc = argc; rv = argv; for (rc--, rv++; rc > 0; rc--, rv++) { - if (strcmp(rv[0], "-m") == 0) { - memdebugging = ISC_TRUE; - isc_mem_debugging = ISC_MEM_DEBUGTRACE | - ISC_MEM_DEBUGRECORD; - return; + if (rv[0][0] != '-') + continue; + option = &rv[0][1]; + while (strpbrk(option, single_dash_opts) == &option[0]) { + if (option[0] == 'm') { + memdebugging = ISC_TRUE; + isc_mem_debugging = ISC_MEM_DEBUGTRACE | + ISC_MEM_DEBUGRECORD; + return; + } + option = &option[1]; } } } - static void parse_args(isc_boolean_t is_batchfile, isc_boolean_t config_only, int argc, char **argv) { @@ -1551,9 +1581,9 @@ parse_args(isc_boolean_t is_batchfile, isc_boolean_t config_only, } /* - * Callback from dighost.c to allow program-specific shutdown code. Here, - * Here, we're possibly reading from a batch file, then shutting down for - * real if there's nothing in the batch file to read. + * Callback from dighost.c to allow program-specific shutdown code. + * Here, we're possibly reading from a batch file, then shutting down + * for real if there's nothing in the batch file to read. */ void dighost_shutdown(void) { @@ -1568,6 +1598,7 @@ dighost_shutdown(void) { return; } + fflush(stdout); if (feof(batchfp)) { batchname = NULL; isc_app_shutdown(); diff --git a/bin/dig/dighost.c b/bin/dig/dighost.c index d5e75a69..ad1fa372 100644 --- a/bin/dig/dighost.c +++ b/bin/dig/dighost.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dighost.c,v 1.221.2.19.2.11 2004/04/13 03:00:06 marka Exp $ */ +/* $Id: dighost.c,v 1.221.2.19.2.12 2004/06/11 00:30:50 marka Exp $ */ /* * Notice to programmers: Do not use this code as an example of how to @@ -864,7 +864,7 @@ setup_file_key(void) { dst_key_t *dstkey = NULL; debug("setup_file_key()"); - result = dst_key_fromnamedfile(keyfile, DST_TYPE_PRIVATE, + result = dst_key_fromnamedfile(keyfile, DST_TYPE_PRIVATE | DST_TYPE_KEY, mctx, &dstkey); if (result != ISC_R_SUCCESS) { fprintf(stderr, "Couldn't read key from %s: %s\n", @@ -3552,8 +3552,8 @@ get_trusted_key(isc_mem_t *mctx) return ISC_R_FAILURE; } fclose(fptemp); - result = dst_key_fromnamedfile(filetemp, DST_TYPE_PUBLIC, - mctx, &key); + result = dst_key_fromnamedfile(filetemp, DST_TYPE_PUBLIC | + DST_TYPE_KEY, mctx, &key); removetmpkey(mctx, filetemp); isc_mem_free(mctx, filetemp); if (result != ISC_R_SUCCESS ) { diff --git a/bin/dig/nslookup.c b/bin/dig/nslookup.c index a06b9e33..923ab848 100644 --- a/bin/dig/nslookup.c +++ b/bin/dig/nslookup.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: nslookup.c,v 1.90.2.4.2.4 2004/04/13 03:00:06 marka Exp $ */ +/* $Id: nslookup.c,v 1.90.2.4.2.5 2004/06/07 03:56:25 marka Exp $ */ #include <config.h> @@ -725,6 +725,7 @@ get_next_command(void) { char *ptr, *arg; char *input; + fflush(stdout); buf = isc_mem_allocate(mctx, COMMSIZE); if (buf == NULL) fatal("memory allocation failure"); diff --git a/bin/dnssec/dnssec-keygen.8 b/bin/dnssec/dnssec-keygen.8 index fd4e5680..235c26ea 100644 --- a/bin/dnssec/dnssec-keygen.8 +++ b/bin/dnssec/dnssec-keygen.8 @@ -13,34 +13,36 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: dnssec-keygen.8,v 1.19.12.3 2004/03/08 04:04:16 marka Exp $ +.\" $Id: dnssec-keygen.8,v 1.19.12.5 2004/06/11 02:32:45 marka Exp $ .\" .TH "DNSSEC-KEYGEN" "8" "June 30, 2000" "BIND9" "" .SH NAME dnssec-keygen \- DNSSEC key generation tool .SH SYNOPSIS .sp -\fBdnssec-keygen\fR \fB-a \fIalgorithm\fB\fR \fB-b \fIkeysize\fB\fR \fB-n \fInametype\fB\fR [ \fB-c \fIclass\fB\fR ] [ \fB-e\fR ] [ \fB-f \fIflag\fB\fR ] [ \fB-g \fIgenerator\fB\fR ] [ \fB-h\fR ] [ \fB-p \fIprotocol\fB\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-s \fIstrength\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-v \fIlevel\fB\fR ] \fBname\fR +\fBdnssec-keygen\fR \fB-a \fIalgorithm\fB\fR \fB-b \fIkeysize\fB\fR \fB-n \fInametype\fB\fR [ \fB-c \fIclass\fB\fR ] [ \fB-e\fR ] [ \fB-f \fIflag\fB\fR ] [ \fB-g \fIgenerator\fB\fR ] [ \fB-h\fR ] [ \fB-k\fR ] [ \fB-p \fIprotocol\fB\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-s \fIstrength\fB\fR ] [ \fB-t \fItype\fB\fR ] [ \fB-v \fIlevel\fB\fR ] \fBname\fR .SH "DESCRIPTION" .PP \fBdnssec-keygen\fR generates keys for DNSSEC -(Secure DNS), as defined in RFC 2535. It can also generate +(Secure DNS), as defined in RFC 2535 and RFC <TBA\\>. It can also generate keys for use with TSIG (Transaction Signatures), as defined in RFC 2845. .SH "OPTIONS" .TP \fB-a \fIalgorithm\fB\fR Selects the cryptographic algorithm. The value of -\fBalgorithm\fR must be one of RSAMD5 or RSA, +\fBalgorithm\fR must be one of RSAMD5 (RSA) or RSASHA1, DSA, DH (Diffie Hellman), or HMAC-MD5. These values are case insensitive. -Note that for DNSSEC, DSA is a mandatory to implement algorithm, -and RSA is recommended. For TSIG, HMAC-MD5 is mandatory. +Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, +and DSA is recommended. For TSIG, HMAC-MD5 is mandatory. + +Note 2: HMAC-MD5 and DH automatically set the -k flag. .TP \fB-b \fIkeysize\fB\fR Specifies the number of bits in the key. The choice of key -size depends on the algorithm used. RSA keys must be between +size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between 512 and 2048 bits. Diffie Hellman keys must be between 128 and 4096 bits. DSA keys must be between 512 and 1024 bits and an exact multiple of 64. HMAC-MD5 keys must be @@ -49,8 +51,8 @@ between 1 and 512 bits. \fB-n \fInametype\fB\fR Specifies the owner type of the key. The value of \fBnametype\fR must either be ZONE (for a DNSSEC -zone key), HOST or ENTITY (for a key associated with a host), -or USER (for a key associated with a user). These values are +zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), +USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are case insensitive. .TP \fB-c \fIclass\fB\fR @@ -58,11 +60,11 @@ Indicates that the DNS record containing the key should have the specified class. If not specified, class IN is used. .TP \fB-e\fR -If generating an RSA key, use a large exponent. +If generating an RSAMD5/RSASHA1 key, use a large exponent. .TP \fB-f \fIflag\fB\fR -Set the specified flag in the flag field of the key record. -The only recognized flag is KSK (Key Signing Key). +Set the specified flag in the flag field of the KEY/DNSKEY record. +The only recognized flag is KSK (Key Signing Key) DNSKEY. .TP \fB-g \fIgenerator\fB\fR If generating a Diffie Hellman key, use this generator. @@ -74,6 +76,9 @@ if possible; otherwise the default is 2. Prints a short summary of the options and arguments to \fBdnssec-keygen\fR. .TP +\fB-k\fR +Generate KEY records rather than DNSKEY records. +.TP \fB-p \fIprotocol\fB\fR Sets the protocol value for the generated key. The protocol is a number between 0 and 255. The default is 3 (DNSSEC). @@ -159,8 +164,6 @@ the files \fIKexample.com.+003+26160.key\fR and \fIKexample.com.+003+26160.private\fR .SH "SEE ALSO" .PP -\fBdnssec-makekeyset\fR(8), -\fBdnssec-signkey\fR(8), \fBdnssec-signzone\fR(8), \fIBIND 9 Administrator Reference Manual\fR, \fIRFC 2535\fR, @@ -168,4 +171,4 @@ the files \fIKexample.com.+003+26160.key\fR and \fIRFC 2539\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/bin/dnssec/dnssec-keygen.c b/bin/dnssec/dnssec-keygen.c index f1e5c142..7feaf7c3 100644 --- a/bin/dnssec/dnssec-keygen.c +++ b/bin/dnssec/dnssec-keygen.c @@ -16,7 +16,7 @@ * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dnssec-keygen.c,v 1.48.2.1.10.10 2004/03/10 02:55:50 marka Exp $ */ +/* $Id: dnssec-keygen.c,v 1.48.2.1.10.11 2004/06/11 01:17:34 marka Exp $ */ #include <config.h> @@ -68,7 +68,7 @@ usage(void) { fprintf(stderr, " DH:\t\t[128..4096]\n"); fprintf(stderr, " DSA:\t\t[512..1024] and divisible by 64\n"); fprintf(stderr, " HMAC-MD5:\t[1..512]\n"); - fprintf(stderr, " -n nametype: ZONE | HOST | ENTITY | USER\n"); + fprintf(stderr, " -n nametype: ZONE | HOST | ENTITY | USER | OTHER\n"); fprintf(stderr, " name: owner of the key\n"); fprintf(stderr, "Other options:\n"); fprintf(stderr, " -c <class> (default: IN)\n"); @@ -101,7 +101,7 @@ main(int argc, char **argv) { dst_key_t *key = NULL, *oldkey; dns_fixedname_t fname; dns_name_t *name; - isc_uint16_t flags = 0; + isc_uint16_t flags = 0, ksk = 0; dns_secalg_t alg; isc_boolean_t conflict = ISC_FALSE, null_key = ISC_FALSE; isc_mem_t *mctx = NULL; @@ -143,7 +143,7 @@ main(int argc, char **argv) { break; case 'f': if (strcasecmp(isc_commandline_argument, "KSK") == 0) - flags |= DNS_KEYFLAG_KSK; + ksk = DNS_KEYFLAG_KSK; else fatal("unknown flag '%s'", isc_commandline_argument); @@ -211,17 +211,20 @@ main(int argc, char **argv) { if (algname == NULL) fatal("no algorithm was specified"); - if (strcasecmp(algname, "HMAC-MD5") == 0) + if (strcasecmp(algname, "HMAC-MD5") == 0) { + options |= DST_TYPE_KEY; alg = DST_ALG_HMACMD5; - else { + } else { r.base = algname; r.length = strlen(algname); ret = dns_secalg_fromtext(&alg, &r); if (ret != ISC_R_SUCCESS) fatal("unknown algorithm %s", algname); + if (alg == DST_ALG_DH) + options |= DST_TYPE_KEY; } - if (type != NULL) { + if (type != NULL && (options & DST_TYPE_KEY) != 0) { if (strcasecmp(type, "NOAUTH") == 0) flags |= DNS_KEYTYPE_NOAUTH; else if (strcasecmp(type, "NOCONF") == 0) @@ -271,20 +274,29 @@ main(int argc, char **argv) { fatal("no nametype specified"); if (strcasecmp(nametype, "zone") == 0) flags |= DNS_KEYOWNER_ZONE; - else if (strcasecmp(nametype, "host") == 0 || - strcasecmp(nametype, "entity") == 0) - flags |= DNS_KEYOWNER_ENTITY; - else if (strcasecmp(nametype, "user") == 0) - flags |= DNS_KEYOWNER_USER; - else - fatal("invalid nametype %s", nametype); + else if ((options & DST_TYPE_KEY) != 0) { /* KEY */ + if (strcasecmp(nametype, "host") == 0 || + strcasecmp(nametype, "entity") == 0) + flags |= DNS_KEYOWNER_ENTITY; + else if (strcasecmp(nametype, "user") == 0) + flags |= DNS_KEYOWNER_USER; + else + fatal("invalid KEY nametype %s", nametype); + } else if (strcasecmp(nametype, "other") != 0) /* DNSKEY */ + fatal("invalid DNSKEY nametype %s", nametype); rdclass = strtoclass(classname); - flags |= signatory; + if ((options & DST_TYPE_KEY) != 0) /* KEY */ + flags |= signatory; + else if ((flags & DNS_KEYOWNER_ZONE) != 0) /* DNSKEY */ + flags |= ksk; if (protocol == -1) protocol = DNS_KEYPROTO_DNSSEC; + else if ((options & DST_TYPE_KEY) == 0 && + protocol != DNS_KEYPROTO_DNSSEC) + fatal("invalid DNSKEY protocol: %d", protocol); if ((flags & DNS_KEYFLAG_TYPEMASK) == DNS_KEYTYPE_NOKEY) { if (size > 0) diff --git a/bin/dnssec/dnssec-keygen.docbook b/bin/dnssec/dnssec-keygen.docbook index 548c3b15..a2034d9e 100644 --- a/bin/dnssec/dnssec-keygen.docbook +++ b/bin/dnssec/dnssec-keygen.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: dnssec-keygen.docbook,v 1.3.12.4 2004/03/08 04:04:16 marka Exp $ --> +<!-- $Id: dnssec-keygen.docbook,v 1.3.12.6 2004/06/11 01:17:34 marka Exp $ --> <refentry> <refentryinfo> @@ -45,6 +45,7 @@ <arg><option>-f <replaceable class="parameter">flag</replaceable></option></arg> <arg><option>-g <replaceable class="parameter">generator</replaceable></option></arg> <arg><option>-h</option></arg> + <arg><option>-k</option></arg> <arg><option>-p <replaceable class="parameter">protocol</replaceable></option></arg> <arg><option>-r <replaceable class="parameter">randomdev</replaceable></option></arg> <arg><option>-s <replaceable class="parameter">strength</replaceable></option></arg> @@ -58,7 +59,7 @@ <title>DESCRIPTION</title> <para> <command>dnssec-keygen</command> generates keys for DNSSEC - (Secure DNS), as defined in RFC 2535. It can also generate + (Secure DNS), as defined in RFC 2535 and RFC <TBA\>. It can also generate keys for use with TSIG (Transaction Signatures), as defined in RFC 2845. </para> @@ -73,13 +74,16 @@ <listitem> <para> Selects the cryptographic algorithm. The value of - <option>algorithm</option> must be one of RSAMD5 or RSA, + <option>algorithm</option> must be one of RSAMD5 (RSA) or RSASHA1, DSA, DH (Diffie Hellman), or HMAC-MD5. These values are case insensitive. </para> <para> - Note that for DNSSEC, DSA is a mandatory to implement algorithm, - and RSA is recommended. For TSIG, HMAC-MD5 is mandatory. + Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, + and DSA is recommended. For TSIG, HMAC-MD5 is mandatory. + </para> + <para> + Note 2: HMAC-MD5 and DH automatically set the -k flag. </para> </listitem> </varlistentry> @@ -89,7 +93,7 @@ <listitem> <para> Specifies the number of bits in the key. The choice of key - size depends on the algorithm used. RSA keys must be between + size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between 512 and 2048 bits. Diffie Hellman keys must be between 128 and 4096 bits. DSA keys must be between 512 and 1024 bits and an exact multiple of 64. HMAC-MD5 keys must be @@ -104,8 +108,8 @@ <para> Specifies the owner type of the key. The value of <option>nametype</option> must either be ZONE (for a DNSSEC - zone key), HOST or ENTITY (for a key associated with a host), - or USER (for a key associated with a user). These values are + zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), + USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are case insensitive. </para> </listitem> @@ -125,7 +129,7 @@ <term>-e</term> <listitem> <para> - If generating an RSA key, use a large exponent. + If generating an RSAMD5/RSASHA1 key, use a large exponent. </para> </listitem> </varlistentry> @@ -134,8 +138,8 @@ <term>-f <replaceable class="parameter">flag</replaceable></term> <listitem> <para> - Set the specified flag in the flag field of the key record. - The only recognized flag is KSK (Key Signing Key). + Set the specified flag in the flag field of the KEY/DNSKEY record. + The only recognized flag is KSK (Key Signing Key) DNSKEY. </para> </listitem> </varlistentry> @@ -163,6 +167,15 @@ </varlistentry> <varlistentry> + <term>-k</term> + <listitem> + <para> + Generate KEY records rather than DNSKEY records. + </para> + </listitem> + </varlistentry> + + <varlistentry> <term>-p <replaceable class="parameter">protocol</replaceable></term> <listitem> <para> @@ -303,14 +316,6 @@ <title>SEE ALSO</title> <para> <citerefentry> - <refentrytitle>dnssec-makekeyset</refentrytitle> - <manvolnum>8</manvolnum> - </citerefentry>, - <citerefentry> - <refentrytitle>dnssec-signkey</refentrytitle> - <manvolnum>8</manvolnum> - </citerefentry>, - <citerefentry> <refentrytitle>dnssec-signzone</refentrytitle> <manvolnum>8</manvolnum> </citerefentry>, @@ -324,7 +329,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/dnssec/dnssec-keygen.html b/bin/dnssec/dnssec-keygen.html index b90939d9..cd72fb22 100644 --- a/bin/dnssec/dnssec-keygen.html +++ b/bin/dnssec/dnssec-keygen.html @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: dnssec-keygen.html,v 1.5.2.1.4.3 2004/03/08 04:04:17 marka Exp $ --> +<!-- $Id: dnssec-keygen.html,v 1.5.2.1.4.5 2004/06/11 02:32:45 marka Exp $ --> <HTML ><HEAD @@ -109,6 +109,9 @@ CLASS="OPTION" >-h</TT >] [<TT CLASS="OPTION" +>-k</TT +>] [<TT +CLASS="OPTION" >-p <TT CLASS="REPLACEABLE" ><I @@ -152,7 +155,7 @@ CLASS="REPLACEABLE" ><DIV CLASS="REFSECT1" ><A -NAME="AEN51" +NAME="AEN53" ></A ><H2 >DESCRIPTION</H2 @@ -161,7 +164,7 @@ NAME="AEN51" CLASS="COMMAND" >dnssec-keygen</B > generates keys for DNSSEC - (Secure DNS), as defined in RFC 2535. It can also generate + (Secure DNS), as defined in RFC 2535 and RFC <TBA\>. It can also generate keys for use with TSIG (Transaction Signatures), as defined in RFC 2845. </P @@ -169,7 +172,7 @@ CLASS="COMMAND" ><DIV CLASS="REFSECT1" ><A -NAME="AEN55" +NAME="AEN57" ></A ><H2 >OPTIONS</H2 @@ -191,13 +194,16 @@ CLASS="REPLACEABLE" <TT CLASS="OPTION" >algorithm</TT -> must be one of RSAMD5 or RSA, +> must be one of RSAMD5 (RSA) or RSASHA1, DSA, DH (Diffie Hellman), or HMAC-MD5. These values are case insensitive. </P ><P -> Note that for DNSSEC, DSA is a mandatory to implement algorithm, - and RSA is recommended. For TSIG, HMAC-MD5 is mandatory. +> Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, + and DSA is recommended. For TSIG, HMAC-MD5 is mandatory. + </P +><P +> Note 2: HMAC-MD5 and DH automatically set the -k flag. </P ></DD ><DT @@ -210,7 +216,7 @@ CLASS="REPLACEABLE" ><DD ><P > Specifies the number of bits in the key. The choice of key - size depends on the algorithm used. RSA keys must be between + size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be between 512 and 2048 bits. Diffie Hellman keys must be between 128 and 4096 bits. DSA keys must be between 512 and 1024 bits and an exact multiple of 64. HMAC-MD5 keys must be @@ -231,8 +237,8 @@ CLASS="REPLACEABLE" CLASS="OPTION" >nametype</TT > must either be ZONE (for a DNSSEC - zone key), HOST or ENTITY (for a key associated with a host), - or USER (for a key associated with a user). These values are + zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with a host (KEY)), + USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). These values are case insensitive. </P ></DD @@ -253,7 +259,7 @@ CLASS="REPLACEABLE" >-e</DT ><DD ><P -> If generating an RSA key, use a large exponent. +> If generating an RSAMD5/RSASHA1 key, use a large exponent. </P ></DD ><DT @@ -265,8 +271,8 @@ CLASS="REPLACEABLE" ></DT ><DD ><P -> Set the specified flag in the flag field of the key record. - The only recognized flag is KSK (Key Signing Key). +> Set the specified flag in the flag field of the KEY/DNSKEY record. + The only recognized flag is KSK (Key Signing Key) DNSKEY. </P ></DD ><DT @@ -296,6 +302,13 @@ CLASS="COMMAND" </P ></DD ><DT +>-k</DT +><DD +><P +> Generate KEY records rather than DNSKEY records. + </P +></DD +><DT >-p <TT CLASS="REPLACEABLE" ><I @@ -388,7 +401,7 @@ CLASS="REPLACEABLE" ><DIV CLASS="REFSECT1" ><A -NAME="AEN129" +NAME="AEN136" ></A ><H2 >GENERATED KEYS</H2 @@ -484,7 +497,7 @@ CLASS="FILENAME" ><DIV CLASS="REFSECT1" ><A -NAME="AEN156" +NAME="AEN163" ></A ><H2 >EXAMPLE</H2 @@ -535,7 +548,7 @@ CLASS="FILENAME" ><DIV CLASS="REFSECT1" ><A -NAME="AEN169" +NAME="AEN176" ></A ><H2 >SEE ALSO</H2 @@ -544,20 +557,6 @@ NAME="AEN169" CLASS="CITEREFENTRY" ><SPAN CLASS="REFENTRYTITLE" ->dnssec-makekeyset</SPAN ->(8)</SPAN ->, - <SPAN -CLASS="CITEREFENTRY" -><SPAN -CLASS="REFENTRYTITLE" ->dnssec-signkey</SPAN ->(8)</SPAN ->, - <SPAN -CLASS="CITEREFENTRY" -><SPAN -CLASS="REFENTRYTITLE" >dnssec-signzone</SPAN >(8)</SPAN >, @@ -582,12 +581,12 @@ CLASS="CITETITLE" ><DIV CLASS="REFSECT1" ><A -NAME="AEN185" +NAME="AEN186" ></A ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/bin/dnssec/dnssec-makekeyset.docbook b/bin/dnssec/dnssec-makekeyset.docbook index 2e1734a2..07327481 100644 --- a/bin/dnssec/dnssec-makekeyset.docbook +++ b/bin/dnssec/dnssec-makekeyset.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: dnssec-makekeyset.docbook,v 1.2.2.3.4.1 2004/03/06 10:21:15 marka Exp $ --> +<!-- $Id: dnssec-makekeyset.docbook,v 1.2.2.3.4.2 2004/06/03 02:24:55 marka Exp $ --> <refentry> <refentryinfo> @@ -220,7 +220,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/dnssec/dnssec-signkey.docbook b/bin/dnssec/dnssec-signkey.docbook index 9ce94a1c..8258a3da 100644 --- a/bin/dnssec/dnssec-signkey.docbook +++ b/bin/dnssec/dnssec-signkey.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: dnssec-signkey.docbook,v 1.2.2.2.4.1 2004/03/06 10:21:15 marka Exp $ --> +<!-- $Id: dnssec-signkey.docbook,v 1.2.2.2.4.2 2004/06/03 02:24:55 marka Exp $ --> <refentry> <refentryinfo> @@ -224,7 +224,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/dnssec/dnssec-signzone.8 b/bin/dnssec/dnssec-signzone.8 index 0f1a44ce..a1795b80 100644 --- a/bin/dnssec/dnssec-signzone.8 +++ b/bin/dnssec/dnssec-signzone.8 @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: dnssec-signzone.8,v 1.23.2.1.4.4 2004/03/15 01:02:42 marka Exp $ +.\" $Id: dnssec-signzone.8,v 1.23.2.1.4.6 2004/06/11 02:32:46 marka Exp $ .\" .TH "DNSSEC-SIGNZONE" "8" "June 30, 2000" "BIND9" "" .SH NAME @@ -23,14 +23,12 @@ dnssec-signzone \- DNSSEC zone signing tool \fBdnssec-signzone\fR [ \fB-a\fR ] [ \fB-c \fIclass\fB\fR ] [ \fB-d \fIdirectory\fB\fR ] [ \fB-e \fIend-time\fB\fR ] [ \fB-f \fIoutput-file\fB\fR ] [ \fB-g\fR ] [ \fB-h\fR ] [ \fB-k \fIkey\fB\fR ] [ \fB-l \fIdomain\fB\fR ] [ \fB-i \fIinterval\fB\fR ] [ \fB-n \fInthreads\fB\fR ] [ \fB-o \fIorigin\fB\fR ] [ \fB-p\fR ] [ \fB-r \fIrandomdev\fB\fR ] [ \fB-s \fIstart-time\fB\fR ] [ \fB-t\fR ] [ \fB-v \fIlevel\fB\fR ] [ \fB-z\fR ] \fBzonefile\fR [ \fBkey\fR\fI...\fR ] .SH "DESCRIPTION" .PP -\fBdnssec-signzone\fR signs a zone. It generates NSEC -and RRSIG records and produces a signed version of the zone. If there -is a \fIsignedkey\fR file from the zone's parent, -the parent's signatures will be incorporated into the generated -signed zone file. The security status of delegations from the -signed zone (that is, whether the child zones are secure or not) is +\fBdnssec-signzone\fR signs a zone. It generates +NSEC and RRSIG records and produces a signed version of the +zone. The security status of delegations from the signed zone +(that is, whether the child zones are secure or not) is determined by the presence or absence of a -\fIsignedkey\fR file for each child zone. +\fIkeyset\fR file for each child zone. .SH "OPTIONS" .TP \fB-a\fR @@ -48,7 +46,7 @@ Generate a DLV set in addition to the key (DNSKEY) and DS sets. The domain is appended to the name of the records. .TP \fB-d \fIdirectory\fB\fR -Look for \fIsignedkey\fR files in +Look for \fIkeyset\fR files in \fBdirectory\fR as the directory .TP \fB-g\fR @@ -146,8 +144,8 @@ current directory. The following command signs the \fBexample.com\fR zone with the DSA key generated in the \fBdnssec-keygen\fR man page. The zone's keys must be in the zone. If there are -\fIsignedkey\fR files associated with this zone -or any child zones, they must be in the current directory. +\fIkeyset\fR files associated with child zones, +they must be in the current directory. \fBexample.com\fR, the following command would be issued: .PP @@ -162,9 +160,8 @@ should be referenced in a zone statement in a .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 +Internet Systems Consortium diff --git a/bin/dnssec/dnssec-signzone.c b/bin/dnssec/dnssec-signzone.c index bb538f25..1f7d4029 100644 --- a/bin/dnssec/dnssec-signzone.c +++ b/bin/dnssec/dnssec-signzone.c @@ -16,7 +16,7 @@ * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dnssec-signzone.c,v 1.139.2.2.4.12 2004/04/15 02:10:38 marka Exp $ */ +/* $Id: dnssec-signzone.c,v 1.139.2.2.4.13 2004/06/11 01:17:35 marka Exp $ */ #include <config.h> @@ -222,7 +222,7 @@ signwithkey(dns_name_t *name, dns_rdataset_t *rdataset, dns_rdata_t *rdata, if (result != ISC_R_SUCCESS) { char keystr[KEY_FORMATSIZE]; key_format(key, keystr, sizeof(keystr)); - fatal("key '%s' failed to sign data: %s", + fatal("dnskey '%s' failed to sign data: %s", keystr, isc_result_totext(result)); } INCSTAT(nsigned); @@ -252,30 +252,32 @@ iszonekey(signer_key_t *key) { } /* - * Finds the key that generated a SIG, if possible. First look at the keys + * Finds the key that generated a RRSIG, if possible. First look at the keys * that we've loaded already, and then see if there's a key on disk. */ static signer_key_t * -keythatsigned(dns_rdata_rrsig_t *sig) { +keythatsigned(dns_rdata_rrsig_t *rrsig) { isc_result_t result; dst_key_t *pubkey = NULL, *privkey = NULL; signer_key_t *key; key = ISC_LIST_HEAD(keylist); while (key != NULL) { - if (sig->keyid == dst_key_id(key->key) && - sig->algorithm == dst_key_alg(key->key) && - dns_name_equal(&sig->signer, dst_key_name(key->key))) + if (rrsig->keyid == dst_key_id(key->key) && + rrsig->algorithm == dst_key_alg(key->key) && + dns_name_equal(&rrsig->signer, dst_key_name(key->key))) return key; key = ISC_LIST_NEXT(key, link); } - result = dst_key_fromfile(&sig->signer, sig->keyid, sig->algorithm, - DST_TYPE_PUBLIC, NULL, mctx, &pubkey); + result = dst_key_fromfile(&rrsig->signer, rrsig->keyid, + rrsig->algorithm, DST_TYPE_PUBLIC, + NULL, mctx, &pubkey); if (result != ISC_R_SUCCESS) return (NULL); - result = dst_key_fromfile(&sig->signer, sig->keyid, sig->algorithm, + result = dst_key_fromfile(&rrsig->signer, rrsig->keyid, + rrsig->algorithm, DST_TYPE_PUBLIC | DST_TYPE_PRIVATE, NULL, mctx, &privkey); if (result == ISC_R_SUCCESS) { @@ -288,8 +290,8 @@ keythatsigned(dns_rdata_rrsig_t *sig) { } /* - * Check to see if we expect to find a key at this name. If we see a SIG - * and can't find the signing key that we expect to find, we drop the sig. + * Check to see if we expect to find a key at this name. If we see a RRSIG + * and can't find the signing key that we expect to find, we drop the rrsig. * I'm not sure if this is completely correct, but it seems to work. */ static isc_boolean_t @@ -313,17 +315,17 @@ expecttofindkey(dns_name_t *name) { return (ISC_FALSE); } dns_name_format(name, namestr, sizeof(namestr)); - fatal("failure looking for '%s KEY' in database: %s", + fatal("failure looking for '%s DNSKEY' in database: %s", namestr, isc_result_totext(result)); return (ISC_FALSE); /* removes a warning */ } static inline isc_boolean_t setverifies(dns_name_t *name, dns_rdataset_t *set, signer_key_t *key, - dns_rdata_t *sig) + dns_rdata_t *rrsig) { isc_result_t result; - result = dns_dnssec_verify(name, set, key->key, ISC_FALSE, mctx, sig); + result = dns_dnssec_verify(name, set, key->key, ISC_FALSE, mctx, rrsig); if (result == ISC_R_SUCCESS) { INCSTAT(nverified); return (ISC_TRUE); @@ -334,7 +336,7 @@ setverifies(dns_name_t *name, dns_rdataset_t *set, signer_key_t *key, } /* - * Signs a set. Goes through contortions to decide if each SIG should + * Signs a set. Goes through contortions to decide if each RRSIG should * be dropped or retained, and then determines if any new SIGs need to * be generated. */ @@ -344,7 +346,7 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, { dns_rdataset_t sigset; dns_rdata_t sigrdata = DNS_RDATA_INIT; - dns_rdata_rrsig_t sig; + dns_rdata_rrsig_t rrsig; signer_key_t *key; isc_result_t result; isc_boolean_t nosigs = ISC_FALSE; @@ -370,7 +372,7 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, nosigs = ISC_TRUE; } if (result != ISC_R_SUCCESS) - fatal("failed while looking for '%s SIG %s': %s", + fatal("failed while looking for '%s RRSIG %s': %s", namestr, typestr, isc_result_totext(result)); vbprintf(1, "%s/%s:\n", namestr, typestr); @@ -397,44 +399,44 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, dns_rdataset_current(&sigset, &sigrdata); - result = dns_rdata_tostruct(&sigrdata, &sig, NULL); + result = dns_rdata_tostruct(&sigrdata, &rrsig, NULL); check_result(result, "dns_rdata_tostruct"); - future = isc_serial_lt(now, sig.timesigned); + future = isc_serial_lt(now, rrsig.timesigned); - key = keythatsigned(&sig); - sig_format(&sig, sigstr, sizeof(sigstr)); + key = keythatsigned(&rrsig); + sig_format(&rrsig, sigstr, sizeof(sigstr)); if (key != NULL && issigningkey(key)) - expired = isc_serial_gt(now + cycle, sig.timeexpire); + expired = isc_serial_gt(now + cycle, rrsig.timeexpire); else - expired = isc_serial_gt(now, sig.timeexpire); + expired = isc_serial_gt(now, rrsig.timeexpire); - if (isc_serial_gt(sig.timesigned, sig.timeexpire)) { - /* sig is dropped and not replaced */ - vbprintf(2, "\tsig by %s dropped - " + if (isc_serial_gt(rrsig.timesigned, rrsig.timeexpire)) { + /* rrsig is dropped and not replaced */ + vbprintf(2, "\trrsig by %s dropped - " "invalid validity period\n", sigstr); } else if (key == NULL && !future && - expecttofindkey(&sig.signer)) + expecttofindkey(&rrsig.signer)) { - /* sig is dropped and not replaced */ - vbprintf(2, "\tsig by %s dropped - " - "private key not found\n", + /* rrsig is dropped and not replaced */ + vbprintf(2, "\trrsig by %s dropped - " + "private dnskey not found\n", sigstr); } else if (key == NULL || future) { - vbprintf(2, "\tsig by %s %s - key not found\n", + vbprintf(2, "\trrsig by %s %s - dnskey not found\n", expired ? "retained" : "dropped", sigstr); if (!expired) keep = ISC_TRUE; } else if (issigningkey(key)) { if (!expired && setverifies(name, set, key, &sigrdata)) { - vbprintf(2, "\tsig by %s retained\n", sigstr); + vbprintf(2, "\trrsig by %s retained\n", sigstr); keep = ISC_TRUE; wassignedby[key->position] = ISC_TRUE; nowsignedby[key->position] = ISC_TRUE; } else { - vbprintf(2, "\tsig by %s dropped - %s\n", + vbprintf(2, "\trrsig by %s dropped - %s\n", sigstr, expired ? "expired" : "failed to verify"); @@ -444,22 +446,22 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, } else if (iszonekey(key)) { if (!expired && setverifies(name, set, key, &sigrdata)) { - vbprintf(2, "\tsig by %s retained\n", sigstr); + vbprintf(2, "\trrsig by %s retained\n", sigstr); keep = ISC_TRUE; wassignedby[key->position] = ISC_TRUE; nowsignedby[key->position] = ISC_TRUE; } else { - vbprintf(2, "\tsig by %s dropped - %s\n", + vbprintf(2, "\trrsig by %s dropped - %s\n", sigstr, expired ? "expired" : "failed to verify"); wassignedby[key->position] = ISC_TRUE; } } else if (!expired) { - vbprintf(2, "\tsig by %s retained\n", sigstr); + vbprintf(2, "\trrsig by %s retained\n", sigstr); keep = ISC_TRUE; } else { - vbprintf(2, "\tsig by %s expired\n", sigstr); + vbprintf(2, "\trrsig by %s expired\n", sigstr); } if (keep) { @@ -482,7 +484,7 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, char keystr[KEY_FORMATSIZE]; key_format(key->key, keystr, sizeof(keystr)); - vbprintf(1, "\tresigning with key %s\n", keystr); + vbprintf(1, "\tresigning with dnskey %s\n", keystr); isc_buffer_init(&b, array, sizeof(array)); signwithkey(name, set, &trdata, key->key, &b); nowsignedby[key->position] = ISC_TRUE; @@ -495,7 +497,7 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, } dns_rdata_reset(&sigrdata); - dns_rdata_freestruct(&sig); + dns_rdata_freestruct(&rrsig); result = dns_rdataset_next(&sigset); } if (result == ISC_R_NOMORE) @@ -526,7 +528,7 @@ signset(dns_diff_t *diff, dns_dbnode_t *node, dns_name_t *name, continue; key_format(key->key, keystr, sizeof(keystr)); - vbprintf(1, "\tsigning with key %s\n", keystr); + vbprintf(1, "\tsigning with dnskey %s\n", keystr); dns_rdata_init(&trdata); isc_buffer_init(&b, array, sizeof(array)); signwithkey(name, set, &trdata, key->key, &b); @@ -607,7 +609,7 @@ loadds(dns_name_t *name, isc_uint32_t ttl, dns_rdataset_t *dsset) { return (result); } - vbprintf(2, "found KEY records\n"); + vbprintf(2, "found DNSKEY records\n"); result = dns_db_newversion(db, &ver); check_result(result, "dns_db_newversion"); @@ -753,7 +755,7 @@ delegation(dns_name_t *name, dns_dbnode_t *node, isc_uint32_t *ttlp) { /* * Signs all records at a name. This mostly just signs each set individually, - * but also adds the SIG bit to any NSECs generated earlier, deals with + * but also adds the RRSIG bit to any NSECs generated earlier, deals with * parent/child KEY signatures, and handles other exceptional cases. */ static void @@ -815,9 +817,9 @@ signname(dns_dbnode_t *node, dns_name_t *name) { dns_rdataset_disassociate(&sigdsset); } else if (dns_rdataset_isassociated(&sigdsset)) { result = dns_db_deleterdataset(gdb, node, - gversion, - dns_rdatatype_rrsig, - dns_rdatatype_ds); + gversion, + dns_rdatatype_rrsig, + dns_rdatatype_ds); check_result(result, "dns_db_deleterdataset"); dns_rdataset_disassociate(&sigdsset); } @@ -858,7 +860,7 @@ signname(dns_dbnode_t *node, dns_name_t *name) { while (result == ISC_R_SUCCESS) { dns_rdatasetiter_current(rdsiter, &rdataset); - /* If this is a SIG set, skip it. */ + /* If this is a RRSIG set, skip it. */ if (rdataset.type == dns_rdatatype_rrsig) goto skip; @@ -871,18 +873,11 @@ signname(dns_dbnode_t *node, dns_name_t *name) { if (rdataset.type != dns_rdatatype_nsec && rdataset.type != dns_rdatatype_ds) goto skip; -#if 0 - /* - * The current draft allows DS not at a zone cut. - * This is a bad idea. Update once the RFC is published. - * XXXMPA. - */ } else if (rdataset.type == dns_rdatatype_ds) { char namebuf[DNS_NAME_FORMATSIZE]; dns_name_format(name, namebuf, sizeof(namebuf)); fatal("'%s': found DS RRset without NS RRset\n", namebuf); -#endif } signset(&diff, node, name, &rdataset); @@ -979,7 +974,7 @@ soattl(void) { } /* - * Delete any SIG records at a node. + * Delete any RRSIG records at a node. */ static void cleannode(dns_db_t *db, dns_dbversion_t *version, dns_dbnode_t *node) { @@ -1411,8 +1406,8 @@ warnifallksk(dns_db_t *db) { dns_db_detachnode(db, &node); dns_db_closeversion(db, ¤tversion, ISC_FALSE); if (!have_non_ksk && !ignoreksk) - fprintf(stderr, - "%s: warning: No non-KSK key found. Supply non-KSK key or use '-z'.\n", + fprintf(stderr, "%s: warning: No non-KSK dnskey found. " + "Supply non-KSK dnskey or use '-z'.\n", program); } @@ -1568,9 +1563,9 @@ usage(void) { fprintf(stderr, "\t-g:\t"); fprintf(stderr, "generate DS records from keyset files\n"); fprintf(stderr, "\t-s YYYYMMDDHHMMSS|+offset:\n"); - fprintf(stderr, "\t\tSIG start time - absolute|offset (now - 1 hour)\n"); + fprintf(stderr, "\t\tRRSIG start time - absolute|offset (now - 1 hour)\n"); fprintf(stderr, "\t-e YYYYMMDDHHMMSS|+offset|\"now\"+offset]:\n"); - fprintf(stderr, "\t\tSIG end time - absolute|from start|from now " + fprintf(stderr, "\t\tRRSIG end time - absolute|from start|from now " "(now + 30 days)\n"); fprintf(stderr, "\t-i interval:\n"); fprintf(stderr, "\t\tcycle interval - resign " @@ -1592,6 +1587,8 @@ usage(void) { fprintf(stderr, "\t-n ncpus (number of cpus present)\n"); fprintf(stderr, "\t-k key_signing_key\n"); fprintf(stderr, "\t-l lookasidezone\n"); + fprintf(stderr, "\t-z:\t"); + fprintf(stderr, "ignore KSK flag in DNSKEYs"); fprintf(stderr, "\n"); @@ -1850,7 +1847,7 @@ main(int argc, char *argv[]) { DST_TYPE_PRIVATE, mctx, &newkey); if (result != ISC_R_SUCCESS) - fatal("cannot load key %s: %s", argv[i], + fatal("cannot load dnskey %s: %s", argv[i], isc_result_totext(result)); key = ISC_LIST_HEAD(keylist); @@ -1863,7 +1860,7 @@ main(int argc, char *argv[]) { { if (!dst_key_isprivate(dkey)) fatal("cannot sign zone with " - "non-private key %s", + "non-private dnskey %s", argv[i]); break; } @@ -1887,7 +1884,7 @@ main(int argc, char *argv[]) { DST_TYPE_PRIVATE, mctx, &newkey); if (result != ISC_R_SUCCESS) - fatal("cannot load key %s: %s", dskeyfile[i], + fatal("cannot load dnskey %s: %s", dskeyfile[i], isc_result_totext(result)); key = ISC_LIST_HEAD(keylist); @@ -1909,7 +1906,7 @@ main(int argc, char *argv[]) { key = ISC_LIST_NEXT(key, link); } if (key == NULL) { - /* Override key flags. */ + /* Override dnskey flags. */ key = newkeystruct(newkey, ISC_TRUE); key->isksk = ISC_TRUE; key->isdsk = ISC_FALSE; diff --git a/bin/dnssec/dnssec-signzone.docbook b/bin/dnssec/dnssec-signzone.docbook index 5c12c4e8..2b85102a 100644 --- a/bin/dnssec/dnssec-signzone.docbook +++ b/bin/dnssec/dnssec-signzone.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: dnssec-signzone.docbook,v 1.2.2.2.4.6 2004/03/10 02:55:51 marka Exp $ --> +<!-- $Id: dnssec-signzone.docbook,v 1.2.2.2.4.8 2004/06/11 01:17:35 marka Exp $ --> <refentry> <refentryinfo> @@ -63,14 +63,12 @@ <refsect1> <title>DESCRIPTION</title> <para> - <command>dnssec-signzone</command> signs a zone. It generates NSEC - and RRSIG records and produces a signed version of the zone. If there - is a <filename>signedkey</filename> file from the zone's parent, - the parent's signatures will be incorporated into the generated - signed zone file. The security status of delegations from the - signed zone (that is, whether the child zones are secure or not) is - determined by the presence or absence of a - <filename>signedkey</filename> file for each child zone. + <command>dnssec-signzone</command> signs a zone. It generates + NSEC and RRSIG records and produces a signed version of the + zone. The security status of delegations from the signed zone + (that is, whether the child zones are secure or not) is + determined by the presence or absence of a + <filename>keyset</filename> file for each child zone. </para> </refsect1> @@ -120,7 +118,7 @@ <term>-d <replaceable class="parameter">directory</replaceable></term> <listitem> <para> - Look for <filename>signedkey</filename> files in + Look for <filename>keyset</filename> files in <option>directory</option> as the directory </para> </listitem> @@ -317,8 +315,8 @@ The following command signs the <userinput>example.com</userinput> zone with the DSA key generated in the <command>dnssec-keygen</command> man page. The zone's keys must be in the zone. If there are - <filename>signedkey</filename> files associated with this zone - or any child zones, they must be in the current directory. + <filename>keyset</filename> files associated with child zones, + they must be in the current directory. <userinput>example.com</userinput>, the following command would be issued: </para> @@ -343,10 +341,6 @@ <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> @@ -355,7 +349,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/dnssec/dnssec-signzone.html b/bin/dnssec/dnssec-signzone.html index 9c2e96f4..139be9ab 100644 --- a/bin/dnssec/dnssec-signzone.html +++ b/bin/dnssec/dnssec-signzone.html @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: dnssec-signzone.html,v 1.4.2.1.4.4 2004/03/15 01:02:42 marka Exp $ --> +<!-- $Id: dnssec-signzone.html,v 1.4.2.1.4.6 2004/06/11 02:32:46 marka Exp $ --> <HTML ><HEAD @@ -189,26 +189,21 @@ NAME="AEN66" > <B CLASS="COMMAND" >dnssec-signzone</B -> signs a zone. It generates NSEC - and RRSIG records and produces a signed version of the zone. If there - is a <TT -CLASS="FILENAME" ->signedkey</TT -> file from the zone's parent, - the parent's signatures will be incorporated into the generated - signed zone file. The security status of delegations from the - signed zone (that is, whether the child zones are secure or not) is - determined by the presence or absence of a +> signs a zone. It generates + NSEC and RRSIG records and produces a signed version of the + zone. The security status of delegations from the signed zone + (that is, whether the child zones are secure or not) is + determined by the presence or absence of a <TT CLASS="FILENAME" ->signedkey</TT +>keyset</TT > file for each child zone. </P ></DIV ><DIV CLASS="REFSECT1" ><A -NAME="AEN72" +NAME="AEN71" ></A ><H2 >OPTIONS</H2 @@ -273,7 +268,7 @@ CLASS="REPLACEABLE" ><P > Look for <TT CLASS="FILENAME" ->signedkey</TT +>keyset</TT > files in <TT CLASS="OPTION" @@ -515,7 +510,7 @@ CLASS="REPLACEABLE" ><DIV CLASS="REFSECT1" ><A -NAME="AEN182" +NAME="AEN181" ></A ><H2 >EXAMPLE</H2 @@ -533,9 +528,9 @@ CLASS="COMMAND" man page. The zone's keys must be in the zone. If there are <TT CLASS="FILENAME" ->signedkey</TT -> files associated with this zone - or any child zones, they must be in the current directory. +>keyset</TT +> files associated with child zones, + they must be in the current directory. <TT CLASS="USERINPUT" ><B @@ -574,7 +569,7 @@ CLASS="FILENAME" ><DIV CLASS="REFSECT1" ><A -NAME="AEN196" +NAME="AEN195" ></A ><H2 >SEE ALSO</H2 @@ -586,13 +581,6 @@ 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 @@ -606,12 +594,12 @@ CLASS="CITETITLE" ><DIV CLASS="REFSECT1" ><A -NAME="AEN207" +NAME="AEN203" ></A ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/bin/named/lwresd.8 b/bin/named/lwresd.8 index 6ae18bd2..bbc177d0 100644 --- a/bin/named/lwresd.8 +++ b/bin/named/lwresd.8 @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: lwresd.8,v 1.13.208.1 2004/03/06 07:41:39 marka Exp $ +.\" $Id: lwresd.8,v 1.13.208.2 2004/06/03 05:35:47 marka Exp $ .\" .TH "LWRESD" "8" "June 30, 2000" "BIND9" "" .SH NAME @@ -137,4 +137,4 @@ The default process-id file. \fBresolver\fR(5). .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/bin/named/lwresd.docbook b/bin/named/lwresd.docbook index a552ad9d..46314c26 100644 --- a/bin/named/lwresd.docbook +++ b/bin/named/lwresd.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: lwresd.docbook,v 1.6.208.1 2004/03/06 10:21:20 marka Exp $ --> +<!-- $Id: lwresd.docbook,v 1.6.208.2 2004/06/03 02:24:57 marka Exp $ --> <refentry> <refentryinfo> @@ -286,7 +286,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/named/lwresd.html b/bin/named/lwresd.html index fd084080..3bfef9f0 100644 --- a/bin/named/lwresd.html +++ b/bin/named/lwresd.html @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: lwresd.html,v 1.4.2.1.4.1 2004/03/06 10:21:20 marka Exp $ --> +<!-- $Id: lwresd.html,v 1.4.2.1.4.2 2004/06/03 05:35:47 marka Exp $ --> <HTML ><HEAD @@ -533,7 +533,7 @@ NAME="AEN162" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/bin/named/named.8 b/bin/named/named.8 index 1fed2906..cd120ddc 100644 --- a/bin/named/named.8 +++ b/bin/named/named.8 @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: named.8,v 1.17.208.2 2004/03/06 07:41:39 marka Exp $ +.\" $Id: named.8,v 1.17.208.3 2004/06/03 05:35:47 marka Exp $ .\" .TH "NAMED" "8" "June 30, 2000" "BIND9" "" .SH NAME @@ -174,4 +174,4 @@ The default process-id file. \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/bin/named/named.docbook b/bin/named/named.docbook index df5c1fee..754f1a07 100644 --- a/bin/named/named.docbook +++ b/bin/named/named.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: named.docbook,v 1.5.98.2 2004/03/06 10:21:20 marka Exp $ --> +<!-- $Id: named.docbook,v 1.5.98.3 2004/06/03 02:24:57 marka Exp $ --> <refentry> <refentryinfo> @@ -356,7 +356,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/named/named.html b/bin/named/named.html index 1d4c72ee..45690343 100644 --- a/bin/named/named.html +++ b/bin/named/named.html @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: named.html,v 1.4.2.1.4.2 2004/03/06 10:21:20 marka Exp $ --> +<!-- $Id: named.html,v 1.4.2.1.4.3 2004/06/03 05:35:48 marka Exp $ --> <HTML ><HEAD @@ -661,7 +661,7 @@ NAME="AEN198" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/bin/named/server.c b/bin/named/server.c index 9837a567..3a0c638c 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.339.2.15.2.54 2004/05/14 01:03:44 marka Exp $ */ +/* $Id: server.c,v 1.339.2.15.2.55 2004/06/04 02:32:55 marka Exp $ */ #include <config.h> @@ -1171,14 +1171,42 @@ configure_view(dns_view_t *view, cfg_obj_t *config, cfg_obj_t *vconfig, obj = NULL; result = ns_config_get(maps, "dnssec-lookaside", &obj); if (result == ISC_R_SUCCESS) { - const char *dlv; - isc_buffer_t b; - dlv = cfg_obj_asstring(obj); - isc_buffer_init(&b, dlv, strlen(dlv)); - isc_buffer_add(&b, strlen(dlv)); - CHECK(dns_name_fromtext(dns_fixedname_name(&view->dlv_fixed), - &b, dns_rootname, ISC_TRUE, NULL)); - view->dlv = dns_fixedname_name(&view->dlv_fixed); + for (element = cfg_list_first(obj); + element != NULL; + element = cfg_list_next(element)) + { + const char *str; + isc_buffer_t b; + dns_name_t *dlv; + + obj = cfg_listelt_value(element); +#if 0 + dns_fixedname_t fixed; + dns_name_t *name; + + /* + * When we support multiple dnssec-lookaside + * entries this is how to find the domain to be + * checked. XXXMPA + */ + dns_fixedname_init(&fixed); + name = dns_fixedname_name(&fixed); + str = cfg_obj_asstring(cfg_tuple_get(obj, + "domain")); + isc_buffer_init(&b, str, strlen(str)); + isc_buffer_add(&b, strlen(str)); + CHECK(dns_name_fromtext(name, &b, dns_rootname, + ISC_TRUE, NULL)); +#endif + str = cfg_obj_asstring(cfg_tuple_get(obj, + "trust-anchor")); + isc_buffer_init(&b, str, strlen(str)); + isc_buffer_add(&b, strlen(str)); + dlv = dns_fixedname_name(&view->dlv_fixed); + CHECK(dns_name_fromtext(dlv, &b, dns_rootname, + ISC_TRUE, NULL)); + view->dlv = dns_fixedname_name(&view->dlv_fixed); + } } else view->dlv = NULL; diff --git a/bin/named/tkeyconf.c b/bin/named/tkeyconf.c index c4d9bf8a..7fc13f3d 100644 --- a/bin/named/tkeyconf.c +++ b/bin/named/tkeyconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: tkeyconf.c,v 1.19.208.1 2004/03/06 10:21:21 marka Exp $ */ +/* $Id: tkeyconf.c,v 1.19.208.2 2004/06/11 00:30:51 marka Exp $ */ #include <config.h> @@ -53,6 +53,7 @@ ns_tkeyctx_fromconfig(cfg_obj_t *options, isc_mem_t *mctx, isc_entropy_t *ectx, dns_name_t *name; isc_buffer_t b; cfg_obj_t *obj; + int type; result = dns_tkeyctx_create(mctx, ectx, &tctx); if (result != ISC_R_SUCCESS) @@ -69,9 +70,9 @@ ns_tkeyctx_fromconfig(cfg_obj_t *options, isc_mem_t *mctx, isc_entropy_t *ectx, name = dns_fixedname_name(&fname); RETERR(dns_name_fromtext(name, &b, dns_rootname, ISC_FALSE, NULL)); + type = DST_TYPE_PUBLIC|DST_TYPE_PRIVATE|DST_TYPE_KEY; RETERR(dst_key_fromfile(name, (dns_keytag_t) n, DNS_KEYALG_DH, - DST_TYPE_PUBLIC|DST_TYPE_PRIVATE, - NULL, mctx, &tctx->dhkey)); + type, NULL, mctx, &tctx->dhkey)); } obj = NULL; diff --git a/bin/named/update.c b/bin/named/update.c index 6b396cd0..dea27fd7 100644 --- a/bin/named/update.c +++ b/bin/named/update.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: update.c,v 1.88.2.5.2.19 2004/05/12 06:38:46 marka Exp $ */ +/* $Id: update.c,v 1.88.2.5.2.20 2004/06/04 03:44:45 marka Exp $ */ #include <config.h> @@ -1102,14 +1102,16 @@ add_rr_prepare_action(void *data, rr_t *rr) { isc_result_t result = ISC_R_SUCCESS; add_rr_prepare_ctx_t *ctx = data; dns_difftuple_t *tuple = NULL; + isc_boolean_t equal; /* * If the update RR is a "duplicate" of the update RR, * the update should be silently ignored. */ - if (dns_rdata_compare(&rr->rdata, ctx->update_rr) == 0 && - rr->ttl == ctx->update_rr_ttl) { + equal = ISC_TF(dns_rdata_compare(&rr->rdata, ctx->update_rr) == 0); + if (equal && rr->ttl == ctx->update_rr_ttl) { ctx->ignore_add = ISC_TRUE; + return (ISC_R_SUCCESS); } /* @@ -1137,12 +1139,14 @@ add_rr_prepare_action(void *data, rr_t *rr) { &rr->rdata, &tuple)); dns_diff_append(&ctx->del_diff, &tuple); - CHECK(dns_difftuple_create(ctx->add_diff.mctx, - DNS_DIFFOP_ADD, ctx->name, - ctx->update_rr_ttl, - &rr->rdata, - &tuple)); - dns_diff_append(&ctx->add_diff, &tuple); + if (!equal) { + CHECK(dns_difftuple_create(ctx->add_diff.mctx, + DNS_DIFFOP_ADD, ctx->name, + ctx->update_rr_ttl, + &rr->rdata, + &tuple)); + dns_diff_append(&ctx->add_diff, &tuple); + } } failure: return (result); diff --git a/bin/nsupdate/nsupdate.c b/bin/nsupdate/nsupdate.c index 13e0aac3..cb30a5f3 100644 --- a/bin/nsupdate/nsupdate.c +++ b/bin/nsupdate/nsupdate.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: nsupdate.c,v 1.103.2.15.2.15 2004/05/12 04:47:16 marka Exp $ */ +/* $Id: nsupdate.c,v 1.103.2.15.2.16 2004/06/17 01:00:38 sra Exp $ */ #include <config.h> @@ -346,7 +346,8 @@ setup_keyfile(void) { debug("Creating key..."); - result = dst_key_fromnamedfile(keyfile, DST_TYPE_PRIVATE, mctx, + result = dst_key_fromnamedfile(keyfile, + DST_TYPE_PRIVATE | DST_TYPE_KEY, mctx, &dstkey); if (result != ISC_R_SUCCESS) { fprintf(stderr, "could not read key from %s: %s\n", diff --git a/bin/rndc/rndc-confgen.8 b/bin/rndc/rndc-confgen.8 index d3bd35e8..b12e90cc 100644 --- a/bin/rndc/rndc-confgen.8 +++ b/bin/rndc/rndc-confgen.8 @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: rndc-confgen.8,v 1.3.2.5.2.2 2004/03/06 07:41:40 marka Exp $ +.\" $Id: rndc-confgen.8,v 1.3.2.5.2.3 2004/06/03 05:35:48 marka Exp $ .\" .TH "RNDC-CONFGEN" "8" "Aug 27, 2001" "BIND9" "" .SH NAME @@ -137,4 +137,4 @@ run \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/bin/rndc/rndc-confgen.docbook b/bin/rndc/rndc-confgen.docbook index 5f82e7e1..272de459 100644 --- a/bin/rndc/rndc-confgen.docbook +++ b/bin/rndc/rndc-confgen.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: rndc-confgen.docbook,v 1.3.2.1.4.2 2004/03/06 10:21:32 marka Exp $ --> +<!-- $Id: rndc-confgen.docbook,v 1.3.2.1.4.3 2004/06/03 02:24:58 marka Exp $ --> <refentry> <refentryinfo> @@ -260,7 +260,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/rndc/rndc-confgen.html b/bin/rndc/rndc-confgen.html index 09f3d51a..9d0ccc77 100644 --- a/bin/rndc/rndc-confgen.html +++ b/bin/rndc/rndc-confgen.html @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: rndc-confgen.html,v 1.3.2.5.2.2 2004/03/06 10:21:32 marka Exp $ --> +<!-- $Id: rndc-confgen.html,v 1.3.2.5.2.3 2004/06/03 05:35:49 marka Exp $ --> <HTML ><HEAD @@ -566,7 +566,7 @@ NAME="AEN173" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/bin/rndc/rndc.8 b/bin/rndc/rndc.8 index d57f5863..356883bc 100644 --- a/bin/rndc/rndc.8 +++ b/bin/rndc/rndc.8 @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: rndc.8,v 1.24.206.1 2004/03/06 07:41:40 marka Exp $ +.\" $Id: rndc.8,v 1.24.206.2 2004/06/03 05:35:49 marka Exp $ .\" .TH "RNDC" "8" "June 30, 2000" "BIND9" "" .SH NAME @@ -115,4 +115,4 @@ Several error messages could be clearer. \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/bin/rndc/rndc.conf.5 b/bin/rndc/rndc.conf.5 index 47e71973..5b61cfb0 100644 --- a/bin/rndc/rndc.conf.5 +++ b/bin/rndc/rndc.conf.5 @@ -13,7 +13,7 @@ .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR .\" PERFORMANCE OF THIS SOFTWARE. .\" -.\" $Id: rndc.conf.5,v 1.21.206.1 2004/03/06 07:41:40 marka Exp $ +.\" $Id: rndc.conf.5,v 1.21.206.2 2004/06/03 05:35:50 marka Exp $ .\" .TH "RNDC.CONF" "5" "June 30, 2000" "BIND9" "" .SH NAME @@ -139,4 +139,4 @@ BIND 9 Administrator Reference Manual for details. \fIBIND 9 Administrator Reference Manual\fR. .SH "AUTHOR" .PP -Internet Software Consortium +Internet Systems Consortium diff --git a/bin/rndc/rndc.conf.docbook b/bin/rndc/rndc.conf.docbook index 6ca7d461..95f158b7 100644 --- a/bin/rndc/rndc.conf.docbook +++ b/bin/rndc/rndc.conf.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: rndc.conf.docbook,v 1.4.206.1 2004/03/06 10:21:32 marka Exp $ --> +<!-- $Id: rndc.conf.docbook,v 1.4.206.2 2004/06/03 02:24:58 marka Exp $ --> <refentry> <refentryinfo> @@ -196,7 +196,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/rndc/rndc.conf.html b/bin/rndc/rndc.conf.html index eb2fe25f..c91f5d84 100644 --- a/bin/rndc/rndc.conf.html +++ b/bin/rndc/rndc.conf.html @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: rndc.conf.html,v 1.5.2.1.4.1 2004/03/06 10:21:32 marka Exp $ --> +<!-- $Id: rndc.conf.html,v 1.5.2.1.4.2 2004/06/03 05:35:50 marka Exp $ --> <HTML ><HEAD @@ -373,7 +373,7 @@ NAME="AEN91" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/bin/rndc/rndc.docbook b/bin/rndc/rndc.docbook index 371aee96..d4529ccf 100644 --- a/bin/rndc/rndc.docbook +++ b/bin/rndc/rndc.docbook @@ -16,7 +16,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: rndc.docbook,v 1.7.206.1 2004/03/06 10:21:32 marka Exp $ --> +<!-- $Id: rndc.docbook,v 1.7.206.2 2004/06/03 02:24:58 marka Exp $ --> <refentry> <refentryinfo> @@ -214,7 +214,7 @@ <refsect1> <title>AUTHOR</title> <para> - <corpauthor>Internet Software Consortium</corpauthor> + <corpauthor>Internet Systems Consortium</corpauthor> </para> </refsect1> diff --git a/bin/rndc/rndc.html b/bin/rndc/rndc.html index b1b61fcb..6519499b 100644 --- a/bin/rndc/rndc.html +++ b/bin/rndc/rndc.html @@ -15,7 +15,7 @@ - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: rndc.html,v 1.7.2.1.4.1 2004/03/06 10:21:32 marka Exp $ --> +<!-- $Id: rndc.html,v 1.7.2.1.4.2 2004/06/03 05:35:50 marka Exp $ --> <HTML ><HEAD @@ -416,7 +416,7 @@ NAME="AEN118" ><H2 >AUTHOR</H2 ><P -> Internet Software Consortium +> Internet Systems Consortium </P ></DIV ></BODY diff --git a/bin/tests/dst/Ktest.+001+00002.key b/bin/tests/dst/Ktest.+001+00002.key index 7a5ec2fa..a8b4b4d6 100644 --- a/bin/tests/dst/Ktest.+001+00002.key +++ b/bin/tests/dst/Ktest.+001+00002.key @@ -1 +1 @@ -test. IN KEY 49152 2 1 +test. IN DNSKEY 49152 2 1 diff --git a/bin/tests/dst/Ktest.+001+54622.key b/bin/tests/dst/Ktest.+001+54622.key index 2d000cfc..b0277e33 100644 --- a/bin/tests/dst/Ktest.+001+54622.key +++ b/bin/tests/dst/Ktest.+001+54622.key @@ -1 +1 @@ -test. IN KEY 257 3 1 AQPQjwSpaVzxIgRCpiUoozUQKGh2oX8NIFKDOvtxK+tn536OZg2cROKTlgGEHXJK9YHfW/6nzQULTVpb63P+SQMmjCCidb8IYyhItixRztVeJQ== +test. IN DNSKEY 257 3 1 AQPQjwSpaVzxIgRCpiUoozUQKGh2oX8NIFKDOvtxK+tn536OZg2cROKTlgGEHXJK9YHfW/6nzQULTVpb63P+SQMmjCCidb8IYyhItixRztVeJQ== diff --git a/bin/tests/dst/Ktest.+003+23616.key b/bin/tests/dst/Ktest.+003+23616.key index 44ad296d..958d5857 100644 --- a/bin/tests/dst/Ktest.+003+23616.key +++ b/bin/tests/dst/Ktest.+003+23616.key @@ -1 +1 @@ -test. IN KEY 16641 3 3 ANp1//lqDlEfTavcFI+cyudNfgEz73V/K7fSDvkA0eDYcGg/kSvEjAEO/oLWCERltkuC55ZcM/mSv17WF1d/wR6kww/pLI9eXwkjftAYqs5sNxk+mbEGl6zwve9wq5z7IoTY5/J4l7XLCKftg/wGvrzXQhggIkRvEh3myhxd+ouILcpfvTIthWlTKiH59tSJpmgmiSMTE7nDYaf10iVRWN6DMSprgejiH05/fpmyZAt44tyAh4m1wXS5u4tam1PXDJYJozn7EfQ8e2weIv1yC+t6PHSx +test. IN DNSKEY 16641 3 3 ANp1//lqDlEfTavcFI+cyudNfgEz73V/K7fSDvkA0eDYcGg/kSvEjAEO/oLWCERltkuC55ZcM/mSv17WF1d/wR6kww/pLI9eXwkjftAYqs5sNxk+mbEGl6zwve9wq5z7IoTY5/J4l7XLCKftg/wGvrzXQhggIkRvEh3myhxd+ouILcpfvTIthWlTKiH59tSJpmgmiSMTE7nDYaf10iVRWN6DMSprgejiH05/fpmyZAt44tyAh4m1wXS5u4tam1PXDJYJozn7EfQ8e2weIv1yC+t6PHSx diff --git a/bin/tests/dst/Ktest.+003+49667.key b/bin/tests/dst/Ktest.+003+49667.key index 18ab1475..fb73f570 100644 --- a/bin/tests/dst/Ktest.+003+49667.key +++ b/bin/tests/dst/Ktest.+003+49667.key @@ -1 +1 @@ -test. IN KEY 49152 2 3 +test. IN DNSKEY 49152 2 3 diff --git a/bin/tests/dst/dst_test.c b/bin/tests/dst/dst_test.c index 0a642cf7..b891a35e 100644 --- a/bin/tests/dst/dst_test.c +++ b/bin/tests/dst/dst_test.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dst_test.c,v 1.37.206.1 2004/03/06 10:21:43 marka Exp $ */ +/* $Id: dst_test.c,v 1.37.206.2 2004/06/11 00:30:52 marka Exp $ */ #include <config.h> @@ -160,7 +160,7 @@ dh(dns_name_t *name1, int id1, dns_name_t *name2, int id2, isc_mem_t *mctx) { isc_region_t r1, r2; unsigned char array1[1024], array2[1024]; int alg = DST_ALG_DH; - int type = DST_TYPE_PUBLIC|DST_TYPE_PRIVATE; + int type = DST_TYPE_PUBLIC|DST_TYPE_PRIVATE|DST_TYPE_KEY; ret = dst_key_fromfile(name1, id1, alg, type, current, mctx, &key1); printf("read(%d) returned: %s\n", alg, isc_result_totext(ret)); diff --git a/bin/tests/dst/t_dst.c b/bin/tests/dst/t_dst.c index f4279b23..da654a37 100644 --- a/bin/tests/dst/t_dst.c +++ b/bin/tests/dst/t_dst.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: t_dst.c,v 1.47.206.1 2004/03/06 10:21:43 marka Exp $ */ +/* $Id: t_dst.c,v 1.47.206.2 2004/06/11 00:30:52 marka Exp $ */ #include <config.h> @@ -168,7 +168,7 @@ dh(dns_name_t *name1, int id1, dns_name_t *name2, int id2, isc_mem_t *mctx, char tmp[PATH_MAX + 1]; char *p; int alg = DST_ALG_DH; - int type = DST_TYPE_PUBLIC|DST_TYPE_PRIVATE; + int type = DST_TYPE_PUBLIC|DST_TYPE_PRIVATE|DST_TYPE_KEY; unsigned char array1[1024], array2[1024]; isc_buffer_t b1, b2; isc_region_t r1, r2; diff --git a/bin/tests/system/dlv/ns5/named.conf b/bin/tests/system/dlv/ns5/named.conf index 1d538184..22126ba7 100644 --- a/bin/tests/system/dlv/ns5/named.conf +++ b/bin/tests/system/dlv/ns5/named.conf @@ -14,7 +14,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.2.4.1 2004/05/14 05:20:50 marka Exp $ */ +/* $Id: named.conf,v 1.2.4.2 2004/06/04 02:32:56 marka Exp $ */ /* * Choose a keyname that is unlikely to clash with any real key names. @@ -58,7 +58,7 @@ options { recursion yes; notify yes; dnssec-enable yes; - dnssec-lookaside "dlv.utld"; + dnssec-lookaside "." trust-anchor "dlv.utld"; }; zone "." { type hint; file "hints"; }; diff --git a/bin/tests/system/dnssec/ns6/named.conf b/bin/tests/system/dnssec/ns6/named.conf index 6d87c783..f5282d74 100644 --- a/bin/tests/system/dnssec/ns6/named.conf +++ b/bin/tests/system/dnssec/ns6/named.conf @@ -14,7 +14,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.5.2.2 2004/03/10 02:55:55 marka Exp $ */ +/* $Id: named.conf,v 1.5.2.3 2004/06/04 02:32:57 marka Exp $ */ // NS6 @@ -32,7 +32,7 @@ options { notify yes; disable-algorithms . { DSA; }; dnssec-enable yes; - dnssec-lookaside dlv; + dnssec-lookaside . trust-anchor dlv; }; zone "." { diff --git a/bin/tests/system/ifconfig.sh b/bin/tests/system/ifconfig.sh index fb79667c..fb79667c 100644..100755 --- a/bin/tests/system/ifconfig.sh +++ b/bin/tests/system/ifconfig.sh diff --git a/bin/tests/system/tkey/keycreate.c b/bin/tests/system/tkey/keycreate.c index 04f6437b..60b6743b 100644 --- a/bin/tests/system/tkey/keycreate.c +++ b/bin/tests/system/tkey/keycreate.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: keycreate.c,v 1.7.12.4 2004/03/08 09:04:17 marka Exp $ */ +/* $Id: keycreate.c,v 1.7.12.5 2004/06/11 00:30:53 marka Exp $ */ #include <config.h> @@ -75,6 +75,7 @@ recvquery(isc_task_t *task, isc_event_t *event) { dns_message_t *query, *response; char keyname[256]; isc_buffer_t keynamebuf; + int type; UNUSED(task); @@ -115,8 +116,8 @@ recvquery(isc_task_t *task, isc_event_t *event) { CHECK("dst_key_buildfilename", result); printf("%.*s\n", (int)isc_buffer_usedlength(&keynamebuf), (char *)isc_buffer_base(&keynamebuf)); - result = dst_key_tofile(tsigkey->key, - DST_TYPE_PRIVATE | DST_TYPE_PUBLIC, ""); + type = DST_TYPE_PRIVATE | DST_TYPE_PUBLIC | DST_TYPE_KEY; + result = dst_key_tofile(tsigkey->key, type, ""); CHECK("dst_key_tofile", result); dns_message_destroy(&query); @@ -209,6 +210,7 @@ main(int argc, char *argv[]) { isc_logconfig_t *logconfig; isc_task_t *task; isc_result_t result; + int type; RUNCHECK(isc_app_start()); @@ -280,9 +282,8 @@ main(int argc, char *argv[]) { RUNCHECK(isc_app_onrun(mctx, task, sendquery, NULL)); ourkey = NULL; - result = dst_key_fromnamedfile(ourkeyname, - DST_TYPE_PUBLIC | DST_TYPE_PRIVATE, - mctx, &ourkey); + type = DST_TYPE_PUBLIC | DST_TYPE_PRIVATE | DST_TYPE_KEY; + result = dst_key_fromnamedfile(ourkeyname, type, mctx, &ourkey); CHECK("dst_key_fromnamedfile", result); isc_buffer_init(&nonce, noncedata, sizeof(noncedata)); diff --git a/bin/tests/system/tkey/keydelete.c b/bin/tests/system/tkey/keydelete.c index 90f92166..8f3cb809 100644 --- a/bin/tests/system/tkey/keydelete.c +++ b/bin/tests/system/tkey/keydelete.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: keydelete.c,v 1.4.206.2 2004/03/08 02:07:49 marka Exp $ */ +/* $Id: keydelete.c,v 1.4.206.3 2004/06/11 00:30:53 marka Exp $ */ #include <config.h> @@ -154,6 +154,7 @@ main(int argc, char **argv) { isc_logconfig_t *logconfig; isc_task_t *task; isc_result_t result; + int type; RUNCHECK(isc_app_start()); @@ -222,9 +223,8 @@ main(int argc, char **argv) { RUNCHECK(isc_app_onrun(mctx, task, sendquery, NULL)); dstkey = NULL; - result = dst_key_fromnamedfile(keyname, - DST_TYPE_PUBLIC | DST_TYPE_PRIVATE, - mctx, &dstkey); + type = DST_TYPE_PUBLIC | DST_TYPE_PRIVATE | DST_TYPE_KEY; + result = dst_key_fromnamedfile(keyname, type, mctx, &dstkey); CHECK("dst_key_fromnamedfile", result); result = dns_tsigkey_createfromkey(dst_key_name(dstkey), DNS_TSIG_HMACMD5_NAME, diff --git a/bin/tests/system/tkey/ns1/setup.sh b/bin/tests/system/tkey/ns1/setup.sh index ad1d0f14..b411055d 100644 --- a/bin/tests/system/tkey/ns1/setup.sh +++ b/bin/tests/system/tkey/ns1/setup.sh @@ -15,11 +15,11 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: setup.sh,v 1.2.2.2.10.1 2004/03/06 10:22:35 marka Exp $ +# $Id: setup.sh,v 1.2.2.2.10.2 2004/06/11 00:30:54 marka Exp $ RANDFILE=../random.data -keyname=`$KEYGEN -a DH -b 768 -n host -r $RANDFILE server` +keyname=`$KEYGEN -k -a DH -b 768 -n host -r $RANDFILE server` keyid=`echo $keyname | $PERL -p -e 's/^.*\+0*//;'` rm -f named.conf perl -p -e "s/KEYID/$keyid/;" < named.conf.in > named.conf diff --git a/bin/tests/system/tkey/tests.sh b/bin/tests/system/tkey/tests.sh index 063f33fd..caf16621 100644 --- a/bin/tests/system/tkey/tests.sh +++ b/bin/tests/system/tkey/tests.sh @@ -15,7 +15,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: tests.sh,v 1.2.12.3 2004/03/08 09:04:17 marka Exp $ +# $Id: tests.sh,v 1.2.12.4 2004/06/11 00:30:53 marka Exp $ SYSTEMTESTTOP=.. . $SYSTEMTESTTOP/conf.sh @@ -28,7 +28,7 @@ RANDFILE=random.data echo "I:generating new DH key" ret=0 -dhkeyname=`$KEYGEN -a DH -b 768 -n host -r $RANDFILE client` || ret=1 +dhkeyname=`$KEYGEN -k -a DH -b 768 -n host -r $RANDFILE client` || ret=1 if [ $ret != 0 ]; then echo "I:failed" echo "I:exit status: $status" diff --git a/config.h.in b/config.h.in index 16964b5e..563403bd 100644 --- a/config.h.in +++ b/config.h.in @@ -16,7 +16,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: config.h.in,v 1.47.2.3.2.9 2004/03/14 23:55:14 marka Exp $ */ +/* $Id: config.h.in,v 1.47.2.3.2.10 2004/05/21 08:25:57 marka Exp $ */ /*** *** This file is not to be included by any public header files, because @@ -137,6 +137,9 @@ int sigwait(const unsigned int *set, int *sig); /* Define if you are running under Compaq TruCluster.. */ #undef HAVE_TRUCLUSTER +/* Define if OpenSSL includes DSA support */ +#undef HAVE_OPENSSL_DSA + /* Define to 1 if you have the <dlfcn.h> header file. */ #undef HAVE_DLFCN_H @@ -14,7 +14,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. # -# $Id: configure,v 1.284.2.19.2.20 2004/05/03 10:49:33 marka Exp $ +# $Id: configure,v 1.284.2.19.2.21 2004/05/21 08:25:57 marka Exp $ # # Portions Copyright (C) 1996-2001 Nominum, Inc. # @@ -29,7 +29,7 @@ # 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. -# From configure.in Revision: 1.294.2.23.2.24 . +# From configure.in Revision: 1.294.2.23.2.25 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.59. # @@ -5040,6 +5040,20 @@ rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftes fi fi + echo "$as_me:$LINENO: checking for OpenSSL DSA support" >&5 +echo $ECHO_N "checking for OpenSSL DSA support... $ECHO_C" >&6 + if test -f $use_openssl/include/openssl/dsa.h + then + cat >>confdefs.h <<\_ACEOF +#define HAVE_OPENSSL_DSA 1 +_ACEOF + + echo "$as_me:$LINENO: result: yes" >&5 +echo "${ECHO_T}yes" >&6 + else + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 + fi CFLAGS="$saved_cflags" LIBS="$saved_libs" ;; @@ -7815,7 +7829,7 @@ ia64-*-hpux*) ;; *-*-irix6*) # Find out which ABI we are using. - echo '#line 7818 "configure"' > conftest.$ac_ext + echo '#line 7832 "configure"' > conftest.$ac_ext if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 (eval $ac_compile) 2>&5 ac_status=$? @@ -8805,7 +8819,7 @@ fi # Provide some information about the compiler. -echo "$as_me:8808:" \ +echo "$as_me:8822:" \ "checking for Fortran 77 compiler version" >&5 ac_compiler=`set X $ac_compile; echo $2` { (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5 @@ -9843,11 +9857,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:9846: $lt_compile\"" >&5) + (eval echo "\"\$as_me:9860: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:9850: \$? = $ac_status" >&5 + echo "$as_me:9864: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -10076,11 +10090,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:10079: $lt_compile\"" >&5) + (eval echo "\"\$as_me:10093: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:10083: \$? = $ac_status" >&5 + echo "$as_me:10097: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -10136,11 +10150,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:10139: $lt_compile\"" >&5) + (eval echo "\"\$as_me:10153: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:10143: \$? = $ac_status" >&5 + echo "$as_me:10157: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -12320,7 +12334,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 12323 "configure" +#line 12337 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -12418,7 +12432,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 12421 "configure" +#line 12435 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -14601,11 +14615,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:14604: $lt_compile\"" >&5) + (eval echo "\"\$as_me:14618: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:14608: \$? = $ac_status" >&5 + echo "$as_me:14622: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -14661,11 +14675,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:14664: $lt_compile\"" >&5) + (eval echo "\"\$as_me:14678: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:14668: \$? = $ac_status" >&5 + echo "$as_me:14682: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -16022,7 +16036,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 16025 "configure" +#line 16039 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -16120,7 +16134,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 16123 "configure" +#line 16137 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -16947,11 +16961,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:16950: $lt_compile\"" >&5) + (eval echo "\"\$as_me:16964: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:16954: \$? = $ac_status" >&5 + echo "$as_me:16968: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -17007,11 +17021,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:17010: $lt_compile\"" >&5) + (eval echo "\"\$as_me:17024: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:17014: \$? = $ac_status" >&5 + echo "$as_me:17028: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -19045,11 +19059,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:19048: $lt_compile\"" >&5) + (eval echo "\"\$as_me:19062: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:19052: \$? = $ac_status" >&5 + echo "$as_me:19066: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -19278,11 +19292,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:19281: $lt_compile\"" >&5) + (eval echo "\"\$as_me:19295: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 - echo "$as_me:19285: \$? = $ac_status" >&5 + echo "$as_me:19299: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized # So say no if there are warnings @@ -19338,11 +19352,11 @@ else -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` - (eval echo "\"\$as_me:19341: $lt_compile\"" >&5) + (eval echo "\"\$as_me:19355: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 - echo "$as_me:19345: \$? = $ac_status" >&5 + echo "$as_me:19359: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then # The compiler can only warn and ignore the option if not recognized @@ -21522,7 +21536,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 21525 "configure" +#line 21539 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -21620,7 +21634,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF -#line 21623 "configure" +#line 21637 "configure" #include "confdefs.h" #if HAVE_DLFCN_H diff --git a/configure.in b/configure.in index 7cbfe610..052f4ffa 100644 --- a/configure.in +++ b/configure.in @@ -18,7 +18,7 @@ AC_DIVERT_PUSH(1)dnl esyscmd([sed "s/^/# /" COPYRIGHT])dnl AC_DIVERT_POP()dnl -AC_REVISION($Revision: 1.294.2.23.2.24 $) +AC_REVISION($Revision: 1.294.2.23.2.25 $) AC_INIT(lib/dns/name.c) AC_PREREQ(2.13) @@ -467,6 +467,14 @@ int main() { [AC_MSG_RESULT(not compatible) AC_MSG_ERROR(you need OpenSSL 0.9.6e/0.9.7-beta2 (or newer): CERT CA-2002-23)], [AC_MSG_RESULT(assuming target platform has compatible version)])) + AC_MSG_CHECKING(for OpenSSL DSA support) + if test -f $use_openssl/include/openssl/dsa.h + then + AC_DEFINE(HAVE_OPENSSL_DSA) + AC_MSG_RESULT(yes) + else + AC_MSG_RESULT(no) + fi CFLAGS="$saved_cflags" LIBS="$saved_libs" ;; diff --git a/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.3.0-patch b/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.3.0-patch index e95b1577..7aea9c6e 100644 --- a/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.3.0-patch +++ b/contrib/idn/idnkit-1.0-src/patch/bind9/bind-9.3.0-patch @@ -17,8 +17,8 @@ and install. Index: README.idnkit ---- /dev/null Mon May 17 23:13:53 2004 -+++ README.idnkit Mon May 17 20:30:40 2004 +--- /dev/null Fri Jun 11 12:57:15 2004 ++++ README.idnkit Fri Jun 11 12:40:33 2004 @@ -0,0 +1,113 @@ + + BIND-9 IDN patch @@ -136,18 +136,18 @@ Index: README.idnkit Index: config.h.in =================================================================== RCS file: /proj/cvs/prod/bind9/config.h.in,v -retrieving revision 1.47.2.3.2.9 -diff -U2 -r1.47.2.3.2.9 config.h.in ---- config.h.in 14 Mar 2004 23:55:14 -0000 1.47.2.3.2.9 -+++ config.h.in 17 May 2004 13:17:58 -0000 +retrieving revision 1.47.2.3.2.10 +diff -U2 -r1.47.2.3.2.10 config.h.in +--- config.h.in 21 May 2004 08:25:57 -0000 1.47.2.3.2.10 ++++ config.h.in 11 Jun 2004 03:01:04 -0000 @@ -17,5 +17,5 @@ */ --/* $Id: config.h.in,v 1.47.2.3.2.9 2004/03/14 23:55:14 marka Exp $ */ -+/* $Id: acconfig.h,v 1.35.2.4.2.7 2004/03/08 04:04:12 marka Exp $ */ +-/* $Id: config.h.in,v 1.47.2.3.2.10 2004/05/21 08:25:57 marka Exp $ */ ++/* $Id: acconfig.h,v 1.35.2.4.2.8 2004/05/21 08:24:04 marka Exp $ */ /*** -@@ -165,4 +165,7 @@ +@@ -168,4 +168,7 @@ #undef HAVE_LINUX_CAPABILITY_H +/* Define to 1 if you have the <locale.h> header file. */ @@ -155,7 +155,7 @@ diff -U2 -r1.47.2.3.2.9 config.h.in + /* Define to 1 if you have the <memory.h> header file. */ #undef HAVE_MEMORY_H -@@ -171,4 +174,7 @@ +@@ -174,4 +177,7 @@ #undef HAVE_NET_IF6_H +/* Define to 1 if you have the `setlocale' function. */ @@ -163,7 +163,7 @@ diff -U2 -r1.47.2.3.2.9 config.h.in + /* Define to 1 if you have the <stdint.h> header file. */ #undef HAVE_STDINT_H -@@ -233,4 +239,7 @@ +@@ -236,4 +242,7 @@ /* Define to 1 if you can safely include both <sys/time.h> and <time.h>. */ #undef TIME_WITH_SYS_TIME + @@ -174,14 +174,14 @@ diff -U2 -r1.47.2.3.2.9 config.h.in Index: configure =================================================================== RCS file: /proj/cvs/prod/bind9/configure,v -retrieving revision 1.284.2.19.2.20 -diff -U2 -r1.284.2.19.2.20 configure ---- configure 3 May 2004 10:49:33 -0000 1.284.2.19.2.20 -+++ configure 17 May 2004 13:19:02 -0000 +retrieving revision 1.284.2.19.2.21 +diff -U2 -r1.284.2.19.2.21 configure +--- configure 21 May 2004 08:25:57 -0000 1.284.2.19.2.21 ++++ configure 11 Jun 2004 03:02:59 -0000 @@ -15,5 +15,5 @@ # PERFORMANCE OF THIS SOFTWARE. # --# $Id: configure,v 1.284.2.19.2.20 2004/05/03 10:49:33 marka Exp $ +-# $Id: configure,v 1.284.2.19.2.21 2004/05/21 08:25:57 marka Exp $ +# $Id: COPYRIGHT,v 1.6.2.2.8.2 2004/03/08 04:04:12 marka Exp $ # # Portions Copyright (C) 1996-2001 Nominum, Inc. @@ -201,183 +201,183 @@ diff -U2 -r1.284.2.19.2.20 configure + --with-idnlib=ARG specify libidnkit Some influential environment variables: -@@ -7816,5 +7820,5 @@ +@@ -7830,5 +7834,5 @@ *-*-irix6*) # Find out which ABI we are using. -- echo '#line 7818 "configure"' > conftest.$ac_ext -+ echo '#line 7822 "configure"' > conftest.$ac_ext +- echo '#line 7832 "configure"' > conftest.$ac_ext ++ echo '#line 7836 "configure"' > conftest.$ac_ext if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 (eval $ac_compile) 2>&5 -@@ -8806,5 +8810,5 @@ +@@ -8820,5 +8824,5 @@ # Provide some information about the compiler. --echo "$as_me:8808:" \ -+echo "$as_me:8812:" \ +-echo "$as_me:8822:" \ ++echo "$as_me:8826:" \ "checking for Fortran 77 compiler version" >&5 ac_compiler=`set X $ac_compile; echo $2` -@@ -9844,9 +9848,9 @@ +@@ -9858,9 +9862,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:9846: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:9850: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:9860: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:9864: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:9850: \$? = $ac_status" >&5 -+ echo "$as_me:9854: \$? = $ac_status" >&5 +- echo "$as_me:9864: \$? = $ac_status" >&5 ++ echo "$as_me:9868: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -10077,9 +10081,9 @@ +@@ -10091,9 +10095,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:10079: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:10083: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:10093: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:10097: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:10083: \$? = $ac_status" >&5 -+ echo "$as_me:10087: \$? = $ac_status" >&5 +- echo "$as_me:10097: \$? = $ac_status" >&5 ++ echo "$as_me:10101: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -10137,9 +10141,9 @@ +@@ -10151,9 +10155,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:10139: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:10143: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:10153: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:10157: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 -- echo "$as_me:10143: \$? = $ac_status" >&5 -+ echo "$as_me:10147: \$? = $ac_status" >&5 +- echo "$as_me:10157: \$? = $ac_status" >&5 ++ echo "$as_me:10161: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then -@@ -12321,5 +12325,5 @@ +@@ -12335,5 +12339,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 12323 "configure" -+#line 12327 "configure" +-#line 12337 "configure" ++#line 12341 "configure" #include "confdefs.h" -@@ -12419,5 +12423,5 @@ +@@ -12433,5 +12437,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 12421 "configure" -+#line 12425 "configure" +-#line 12435 "configure" ++#line 12439 "configure" #include "confdefs.h" -@@ -14602,9 +14606,9 @@ +@@ -14616,9 +14620,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:14604: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:14608: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:14618: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:14622: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:14608: \$? = $ac_status" >&5 -+ echo "$as_me:14612: \$? = $ac_status" >&5 +- echo "$as_me:14622: \$? = $ac_status" >&5 ++ echo "$as_me:14626: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -14662,9 +14666,9 @@ +@@ -14676,9 +14680,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:14664: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:14668: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:14678: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:14682: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 -- echo "$as_me:14668: \$? = $ac_status" >&5 -+ echo "$as_me:14672: \$? = $ac_status" >&5 +- echo "$as_me:14682: \$? = $ac_status" >&5 ++ echo "$as_me:14686: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then -@@ -16023,5 +16027,5 @@ +@@ -16037,5 +16041,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 16025 "configure" -+#line 16029 "configure" +-#line 16039 "configure" ++#line 16043 "configure" #include "confdefs.h" -@@ -16121,5 +16125,5 @@ +@@ -16135,5 +16139,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 16123 "configure" -+#line 16127 "configure" +-#line 16137 "configure" ++#line 16141 "configure" #include "confdefs.h" -@@ -16948,9 +16952,9 @@ +@@ -16962,9 +16966,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:16950: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:16954: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:16964: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:16968: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:16954: \$? = $ac_status" >&5 -+ echo "$as_me:16958: \$? = $ac_status" >&5 +- echo "$as_me:16968: \$? = $ac_status" >&5 ++ echo "$as_me:16972: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -17008,9 +17012,9 @@ +@@ -17022,9 +17026,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:17010: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:17014: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:17024: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:17028: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 -- echo "$as_me:17014: \$? = $ac_status" >&5 -+ echo "$as_me:17018: \$? = $ac_status" >&5 +- echo "$as_me:17028: \$? = $ac_status" >&5 ++ echo "$as_me:17032: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then -@@ -19046,9 +19050,9 @@ +@@ -19060,9 +19064,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:19048: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:19052: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:19062: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:19066: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:19052: \$? = $ac_status" >&5 -+ echo "$as_me:19056: \$? = $ac_status" >&5 +- echo "$as_me:19066: \$? = $ac_status" >&5 ++ echo "$as_me:19070: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -19279,9 +19283,9 @@ +@@ -19293,9 +19297,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:19281: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:19285: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:19295: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:19299: $lt_compile\"" >&5) (eval "$lt_compile" 2>conftest.err) ac_status=$? cat conftest.err >&5 -- echo "$as_me:19285: \$? = $ac_status" >&5 -+ echo "$as_me:19289: \$? = $ac_status" >&5 +- echo "$as_me:19299: \$? = $ac_status" >&5 ++ echo "$as_me:19303: \$? = $ac_status" >&5 if (exit $ac_status) && test -s "$ac_outfile"; then # The compiler can only warn and ignore the option if not recognized -@@ -19339,9 +19343,9 @@ +@@ -19353,9 +19357,9 @@ -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \ -e 's:$: $lt_compiler_flag:'` -- (eval echo "\"\$as_me:19341: $lt_compile\"" >&5) -+ (eval echo "\"\$as_me:19345: $lt_compile\"" >&5) +- (eval echo "\"\$as_me:19355: $lt_compile\"" >&5) ++ (eval echo "\"\$as_me:19359: $lt_compile\"" >&5) (eval "$lt_compile" 2>out/conftest.err) ac_status=$? cat out/conftest.err >&5 -- echo "$as_me:19345: \$? = $ac_status" >&5 -+ echo "$as_me:19349: \$? = $ac_status" >&5 +- echo "$as_me:19359: \$? = $ac_status" >&5 ++ echo "$as_me:19363: \$? = $ac_status" >&5 if (exit $ac_status) && test -s out/conftest2.$ac_objext then -@@ -21523,5 +21527,5 @@ +@@ -21537,5 +21541,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 21525 "configure" -+#line 21529 "configure" +-#line 21539 "configure" ++#line 21543 "configure" #include "confdefs.h" -@@ -21621,5 +21625,5 @@ +@@ -21635,5 +21639,5 @@ lt_status=$lt_dlunknown cat > conftest.$ac_ext <<EOF --#line 21623 "configure" -+#line 21627 "configure" +-#line 21637 "configure" ++#line 21641 "configure" #include "confdefs.h" -@@ -27186,4 +27190,354 @@ +@@ -27200,4 +27204,354 @@ # +# IDN support @@ -732,7 +732,7 @@ diff -U2 -r1.284.2.19.2.20 configure +# # Substitutions # -@@ -28066,4 +28420,5 @@ +@@ -28080,4 +28434,5 @@ s,@XMLDCL@,$XMLDCL,;t t s,@DOCBOOK2MANSPEC@,$DOCBOOK2MANSPEC,;t t +s,@IDNLIBS@,$IDNLIBS,;t t @@ -741,11 +741,11 @@ diff -U2 -r1.284.2.19.2.20 configure Index: configure.in =================================================================== RCS file: /proj/cvs/prod/bind9/configure.in,v -retrieving revision 1.294.2.23.2.24 -diff -U2 -r1.294.2.23.2.24 configure.in ---- configure.in 3 May 2004 10:47:32 -0000 1.294.2.23.2.24 -+++ configure.in 17 May 2004 13:19:07 -0000 -@@ -1994,4 +1994,80 @@ +retrieving revision 1.294.2.23.2.25 +diff -U2 -r1.294.2.23.2.25 configure.in +--- configure.in 21 May 2004 08:24:04 -0000 1.294.2.23.2.25 ++++ configure.in 11 Jun 2004 03:03:10 -0000 +@@ -2002,4 +2002,80 @@ # +# IDN support @@ -832,7 +832,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/Makefile.in,v retrieving revision 1.25.12.10 diff -U2 -r1.25.12.10 Makefile.in --- bin/dig/Makefile.in 13 Apr 2004 05:47:32 -0000 1.25.12.10 -+++ bin/dig/Makefile.in 17 May 2004 13:19:07 -0000 ++++ bin/dig/Makefile.in 11 Jun 2004 03:03:10 -0000 @@ -46,5 +46,5 @@ LIBS = ${LWRESLIBS} ${DNSLIBS} ${BIND9LIBS} ${ISCLIBS} \ @@ -846,7 +846,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/dig.1,v retrieving revision 1.14.2.4.2.5 diff -U2 -r1.14.2.4.2.5 dig.1 --- bin/dig/dig.1 13 Apr 2004 04:11:03 -0000 1.14.2.4.2.5 -+++ bin/dig/dig.1 17 May 2004 13:19:08 -0000 ++++ bin/dig/dig.1 11 Jun 2004 03:03:11 -0000 @@ -385,4 +385,15 @@ will not print the initial query when it looks up the NS records for isc.org. @@ -869,7 +869,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/dig.docbook,v retrieving revision 1.4.2.7.4.8 diff -U2 -r1.4.2.7.4.8 dig.docbook --- bin/dig/dig.docbook 13 Apr 2004 03:00:05 -0000 1.4.2.7.4.8 -+++ bin/dig/dig.docbook 17 May 2004 13:19:09 -0000 ++++ bin/dig/dig.docbook 11 Jun 2004 03:03:13 -0000 @@ -575,4 +575,19 @@ <refsect1> @@ -893,10 +893,10 @@ diff -U2 -r1.4.2.7.4.8 dig.docbook Index: bin/dig/dighost.c =================================================================== RCS file: /proj/cvs/prod/bind9/bin/dig/dighost.c,v -retrieving revision 1.221.2.19.2.11 -diff -U2 -r1.221.2.19.2.11 dighost.c ---- bin/dig/dighost.c 13 Apr 2004 03:00:06 -0000 1.221.2.19.2.11 -+++ bin/dig/dighost.c 17 May 2004 13:19:19 -0000 +retrieving revision 1.221.2.19.2.12 +diff -U2 -r1.221.2.19.2.12 dighost.c +--- bin/dig/dighost.c 11 Jun 2004 00:30:50 -0000 1.221.2.19.2.12 ++++ bin/dig/dighost.c 11 Jun 2004 03:03:23 -0000 @@ -42,4 +42,15 @@ #endif @@ -1137,7 +1137,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/host.1,v retrieving revision 1.11.2.1.4.4 diff -U2 -r1.11.2.1.4.4 host.1 --- bin/dig/host.1 13 Apr 2004 04:11:03 -0000 1.11.2.1.4.4 -+++ bin/dig/host.1 17 May 2004 13:19:20 -0000 ++++ bin/dig/host.1 11 Jun 2004 03:03:23 -0000 @@ -128,4 +128,15 @@ will be set to the number of seconds given by the hardware's maximum value for an integer quantity. @@ -1160,7 +1160,7 @@ RCS file: /proj/cvs/prod/bind9/bin/dig/host.docbook,v retrieving revision 1.2.2.2.4.5 diff -U2 -r1.2.2.2.4.5 host.docbook --- bin/dig/host.docbook 13 Apr 2004 01:26:26 -0000 1.2.2.2.4.5 -+++ bin/dig/host.docbook 17 May 2004 13:19:21 -0000 ++++ bin/dig/host.docbook 11 Jun 2004 03:03:24 -0000 @@ -192,4 +192,19 @@ <refsect1> @@ -1187,7 +1187,7 @@ RCS file: /proj/cvs/prod/bind9/lib/dns/name.c,v retrieving revision 1.127.2.7.2.10 diff -U2 -r1.127.2.7.2.10 name.c --- lib/dns/name.c 19 Apr 2004 21:55:38 -0000 1.127.2.7.2.10 -+++ lib/dns/name.c 17 May 2004 13:19:24 -0000 ++++ lib/dns/name.c 11 Jun 2004 03:03:27 -0000 @@ -180,4 +180,11 @@ LIBDNS_EXTERNAL_DATA dns_name_t *dns_wildcardname = &wild; @@ -1233,7 +1233,7 @@ RCS file: /proj/cvs/prod/bind9/lib/dns/include/dns/name.h,v retrieving revision 1.95.2.3.2.8 diff -U2 -r1.95.2.3.2.8 name.h --- lib/dns/include/dns/name.h 16 Mar 2004 12:57:17 -0000 1.95.2.3.2.8 -+++ lib/dns/include/dns/name.h 17 May 2004 13:19:27 -0000 ++++ lib/dns/include/dns/name.h 11 Jun 2004 03:03:32 -0000 @@ -156,4 +156,15 @@ #define DNS_NAME_MAXWIRE 255 diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index d03c0d3f..63f92635 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN" "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"> -<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.41 2004/05/12 02:06:20 marka Exp $ --> +<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.44 2004/06/11 00:21:04 marka Exp $ --> <book> <title>BIND 9 Administrator Reference Manual</title> @@ -989,7 +989,7 @@ protocol is specified in RFC 1996. <command>zone</command> statement.</para> <para>Updating of secure zones (zones using DNSSEC) follows - RFC 3007: SIG and NXT records affected by updates are automatically + RFC 3007: RRSIG and NSEC records affected by updates are automatically regenerated by the server using an online zone key. Update authorization is based on transaction signatures and an explicit server policy.</para> @@ -1433,8 +1433,8 @@ allow-update { key host1-host2. ;}; <title>DNSSEC</title> <para>Cryptographic authentication of DNS information is possible - through the DNS Security (<emphasis>DNSSEC</emphasis>) extensions, - defined in RFC 2535. This section describes the creation and use + through the DNS Security (<emphasis>DNSSEC-bis</emphasis>) extensions, + defined in RFC <TBA>. This section describes the creation and use of DNSSEC signed zones.</para> <para>In order to set up a DNSSEC secure zone, there are a series @@ -1443,15 +1443,17 @@ allow-update { key host1-host2. ;}; that are used in this process, which are explained in more detail below. In all cases, the <option>-h</option> option prints a full list of parameters. Note that the DNSSEC tools require the - keyset and signedkey files to be in the working directory or the + keyset files to be in the working directory or the directory specified by the <option>-h</option> option, and - that the tools shipped with BIND 9.0.x are not fully compatible + that the tools shipped with BIND 9.2.x and earlier are not compatible with the current ones.</para> <para>There must also be communication with the administrators of - the parent and/or child zone to transmit keys and signatures. A - zone's security status must be indicated by the parent zone for a - DNSSEC capable resolver to trust its data.</para> + the parent and/or child zone to transmit keys. A zone's security + status must be indicated by the parent zone for a DNSSEC capable + resolver to trust its data. This is done through the presense + or absence of a <literal>DS</literal> record at the delegation + point.</para> <para>For other servers to trust data in this zone, they must either be statically configured with this zone's zone key or the @@ -1470,16 +1472,16 @@ allow-update { key host1-host2. ;}; <command>ZONE</command>, and must be usable for authentication. It is recommended that zone keys use a cryptographic algorithm designated as "mandatory to implement" by the IETF; currently - these are RSASHA1 and DSA.</para> + the only one is RSASHA1.</para> - <para>The following command will generate a 768 bit DSA key for + <para>The following command will generate a 768 bit RSASHA1 key for the <filename>child.example</filename> zone:</para> - <para><userinput>dnssec-keygen -a DSA -b 768 -n ZONE child.example.</userinput></para> + <para><userinput>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</userinput></para> <para>Two output files will be produced: - <filename>Kchild.example.+003+12345.key</filename> and - <filename>Kchild.example.+003+12345.private</filename> (where + <filename>Kchild.example.+005+12345.key</filename> and + <filename>Kchild.example.+005+12345.private</filename> (where 12345 is an example of a key tag). The key file names contain the key name (<filename>child.example.</filename>), algorithm (3 is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in this case). @@ -1498,78 +1500,18 @@ allow-update { key host1-host2. ;}; </sect2> <sect2> - <title>Creating a Keyset</title> - - <para>The <command>dnssec-makekeyset</command> program is used - to create a key set from one or more keys.</para> - - <para>Once the zone keys have been generated, a key set must be - built for transmission to the administrator of the parent zone, - so that the parent zone can sign the keys with its own zone key - and correctly indicate the security status of this zone. When - building a key set, the list of keys to be included and the TTL - of the set must be specified, and the desired signature validity - period of the parent's signature may also be specified.</para> - - <para>The list of keys to be inserted into the key set may also - included non-zone keys present at the top of the zone. - <command>dnssec-makekeyset</command> may also be used at other - names in the zone.</para> - - <para>The following command generates a key set containing the - above key and another key similarly generated, with a TTL of - 3600 and a signature validity period of 10 days starting from - now.</para> - -<para><userinput>dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para> - - <para>One output file is produced: - <filename>keyset-child.example.</filename>. This file should be - transmitted to the parent to be signed. It includes the keys, - as well as signatures over the key set generated by the zone - keys themselves, which are used to prove ownership of the - private keys and encode the desired validity period.</para> - - </sect2> - <sect2> - <title>Signing the Child's Keyset</title> - - <para>The <command>dnssec-signkey</command> program is used to - sign one child's keyset.</para> - - <para>If the <filename>child.example</filename> zone has any - delegations which are secure, for example, - <filename>grand.child.example</filename>, the - <filename>child.example</filename> administrator should receive - keyset files for each secure subzone. These keys must be signed - by this zone's zone keys.</para> - - <para>The following command signs the child's key set with the - zone keys:</para> - -<para><userinput>dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</userinput></para> - - <para>One output file is produced: - <filename>signedkey-grand.child.example.</filename>. This file - should be both transmitted back to the child and retained. It - includes all keys (the child's keys) from the keyset file and - signatures generated by this zone's zone keys.</para> - - </sect2> - <sect2> <title>Signing the Zone</title> <para>The <command>dnssec-signzone</command> program is used to sign a zone.</para> - <para>Any <filename>signedkey</filename> files corresponding to - secure subzones should be present, as well as a - <filename>signedkey</filename> file for this zone generated by - the parent (if there is one). The zone signer will generate - <literal>NXT</literal> and <literal>SIG</literal> records for - the zone, as well as incorporate the zone key signature from the - parent and indicate the security status at all delegation - points.</para> + <para>Any <filename>keyset</filename> files corresponding + to secure subzones should be present. The zone signer will + generate <literal>NSEC</literal> and <literal>RRSIG</literal> + records for the zone, as well as <literal>DS</literal> for + the child zones if <literal>'-d'</literal> is specified. + If <literal>'-d'</literal> is not specified then DS RRsets for + the secure child zones need to be added manually.</para> <para>The following command signs the zone, assuming it is in a file called <filename>zone.child.example</filename>. By @@ -1583,6 +1525,12 @@ allow-update { key host1-host2. ;}; should be referenced by <filename>named.conf</filename> as the input file for the zone.</para> + <para><command>dnssec-signzone</command> will also produce a + keyset and dsset files and optionally a dlvset file. These + are used to provide the parent zone administators with the + <literal>DNSKEYs</literal> (or their corresponding <literal>DS</literal> + records) that are the secure entry point to the zone.</para> + </sect2> <sect2><title>Configuring Servers</title> @@ -2632,7 +2580,16 @@ the <command>null</command> channel.</para></entry> At startup, specifing the category <command>queries</command> will also enable query logging unless <command>querylog</command> option has been specified. -</para></entry> +</para> +<para> +The query log entry reports the client's IP address and port number. The +query name, class and type. It also reports whether the Recursion Desired +flag was set (+ if set, - if not set), EDNS was in use (E) or if the +query was signed (S).</para> +<programlisting><computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput> +<computeroutput>client ::1#62537: query: www.example.net IN AAAA -SE</computeroutput> +</programlisting> +</entry> </row> <row rowsep = "0"> <entry colname = "1"><para><command>dispatch</command></para></entry> @@ -2758,7 +2715,7 @@ statement in the <filename>named.conf</filename> file:</para> <optional> use-id-pool <replaceable>yes_or_no</replaceable>; </optional> <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable>; </optional> <optional> dnssec-enable <replaceable>yes_or_no</replaceable>; </optional> - <optional> dnssec-lookaside <replaceable>domain</replaceable>; </optional> + <optional> dnssec-lookaside <replaceable>domain</replaceable> trust-anchor <replaceable>domain</replaceable>; </optional> <optional> dnssec-must-be-secure <replaceable>domain yes_or_no</replaceable>; </optional> <optional> forward ( <replaceable>only</replaceable> | <replaceable>first</replaceable> ); </optional> <optional> forwarders { <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; <optional> <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> ; ... </optional> }; </optional> @@ -2985,10 +2942,12 @@ Only the most specific will be applied. <listitem><para> When set <command>dnssec-lookaside</command> provides the validator with an alternate method to validate DNSKEY records at the -top of a zone. When set the domain specified by -<command>dnssec-lookaside</command> is appended to DNSKEY's -name and a DLV record is looked up. If the DLV record validates -a DNSKEY (similarly to the way a DS record does) the DNSKEY RRset is deemed to be trusted. +top of a zone. When a DNSKEY is at or below a domain specified by the +deepest <command>dnssec-lookaside</command>, and the normal dnssec validation +has left the key untrusted, the trust-anchor will be append to the key +name and a DLV record will be looked up to see if it can validate the +key. If the DLV record validates a DNSKEY (similarly to the way a DS +record does) the DNSKEY RRset is deemed to be trusted. </para></listitem></varlistentry> <varlistentry><term><command>dnssec-must-be-secure</command></term> @@ -4755,10 +4714,9 @@ The default is the empty list.</para> <varlistentry><term><command>check-names</command></term> <listitem><para> -This option was used in BIND 8 to restrict the character set of -domain names in master files and/or DNS responses received from the -network. BIND 9 does not restrict the character set of domain names -and does not implement the <command>check-names</command> option. +This option is used to restrict the character set and syntax of +certain domain names in master files and/or DNS responses received from the +network. </para> </listitem></varlistentry> diff --git a/doc/arm/Bv9ARM.ch04.html b/doc/arm/Bv9ARM.ch04.html index 496c45b4..1f9ab62c 100644 --- a/doc/arm/Bv9ARM.ch04.html +++ b/doc/arm/Bv9ARM.ch04.html @@ -121,7 +121,7 @@ HREF="Bv9ARM.ch04.html#DNSSEC" ></DT ><DT >4.9. <A -HREF="Bv9ARM.ch04.html#AEN1019" +HREF="Bv9ARM.ch04.html#AEN1001" >IPv6 Support in <SPAN CLASS="acronym" >BIND</SPAN @@ -209,7 +209,7 @@ CLASS="command" > statement.</P ><P >Updating of secure zones (zones using DNSSEC) follows - RFC 3007: SIG and NXT records affected by updates are automatically + RFC 3007: RRSIG and NSEC records affected by updates are automatically regenerated by the server using an online zone key. Update authorization is based on transaction signatures and an explicit server policy.</P @@ -1184,10 +1184,10 @@ NAME="DNSSEC" CLASS="emphasis" ><I CLASS="emphasis" ->DNSSEC</I +>DNSSEC-bis</I ></SPAN >) extensions, - defined in RFC 2535. This section describes the creation and use + defined in RFC <TBA>. This section describes the creation and use of DNSSEC signed zones.</P ><P >In order to set up a DNSSEC secure zone, there are a series @@ -1202,18 +1202,23 @@ CLASS="option" >-h</TT > option prints a full list of parameters. Note that the DNSSEC tools require the - keyset and signedkey files to be in the working directory or the + keyset files to be in the working directory or the directory specified by the <TT CLASS="option" >-h</TT > option, and - that the tools shipped with BIND 9.0.x are not fully compatible + that the tools shipped with BIND 9.2.x and earlier are not compatible with the current ones.</P ><P >There must also be communication with the administrators of - the parent and/or child zone to transmit keys and signatures. A - zone's security status must be indicated by the parent zone for a - DNSSEC capable resolver to trust its data.</P + the parent and/or child zone to transmit keys. A zone's security + status must be indicated by the parent zone for a DNSSEC capable + resolver to trust its data. This is done through the presense + or absence of a <TT +CLASS="literal" +>DS</TT +> record at the delegation + point.</P ><P >For other servers to trust data in this zone, they must either be statically configured with this zone's zone key or the @@ -1223,7 +1228,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN951" +NAME="AEN952" >4.8.1. Generating Keys</A ></H2 ><P @@ -1243,9 +1248,9 @@ CLASS="command" >, and must be usable for authentication. It is recommended that zone keys use a cryptographic algorithm designated as "mandatory to implement" by the IETF; currently - these are RSASHA1 and DSA.</P + the only one is RSASHA1.</P ><P ->The following command will generate a 768 bit DSA key for +>The following command will generate a 768 bit RSASHA1 key for the <TT CLASS="filename" >child.example</TT @@ -1254,18 +1259,18 @@ CLASS="filename" ><TT CLASS="userinput" ><B ->dnssec-keygen -a DSA -b 768 -n ZONE child.example.</B +>dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.</B ></TT ></P ><P >Two output files will be produced: <TT CLASS="filename" ->Kchild.example.+003+12345.key</TT +>Kchild.example.+005+12345.key</TT > and <TT CLASS="filename" ->Kchild.example.+003+12345.private</TT +>Kchild.example.+005+12345.private</TT > (where 12345 is an example of a key tag). The key file names contain the key name (<TT @@ -1303,111 +1308,8 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN971" ->4.8.2. Creating a Keyset</A -></H2 -><P ->The <B -CLASS="command" ->dnssec-makekeyset</B -> program is used - to create a key set from one or more keys.</P -><P ->Once the zone keys have been generated, a key set must be - built for transmission to the administrator of the parent zone, - so that the parent zone can sign the keys with its own zone key - and correctly indicate the security status of this zone. When - building a key set, the list of keys to be included and the TTL - of the set must be specified, and the desired signature validity - period of the parent's signature may also be specified.</P -><P ->The list of keys to be inserted into the key set may also - included non-zone keys present at the top of the zone. - <B -CLASS="command" ->dnssec-makekeyset</B -> may also be used at other - names in the zone.</P -><P ->The following command generates a key set containing the - above key and another key similarly generated, with a TTL of - 3600 and a signature validity period of 10 days starting from - now.</P -><P -><TT -CLASS="userinput" -><B ->dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456</B -></TT -></P -><P ->One output file is produced: - <TT -CLASS="filename" ->keyset-child.example.</TT ->. This file should be - transmitted to the parent to be signed. It includes the keys, - as well as signatures over the key set generated by the zone - keys themselves, which are used to prove ownership of the - private keys and encode the desired validity period.</P -></DIV -><DIV -CLASS="sect2" -><H2 -CLASS="sect2" -><A -NAME="AEN983" ->4.8.3. Signing the Child's Keyset</A -></H2 -><P ->The <B -CLASS="command" ->dnssec-signkey</B -> program is used to - sign one child's keyset.</P -><P ->If the <TT -CLASS="filename" ->child.example</TT -> zone has any - delegations which are secure, for example, - <TT -CLASS="filename" ->grand.child.example</TT ->, the - <TT -CLASS="filename" ->child.example</TT -> administrator should receive - keyset files for each secure subzone. These keys must be signed - by this zone's zone keys.</P -><P ->The following command signs the child's key set with the - zone keys:</P -><P -><TT -CLASS="userinput" -><B ->dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456</B -></TT -></P -><P ->One output file is produced: - <TT -CLASS="filename" ->signedkey-grand.child.example.</TT ->. This file - should be both transmitted back to the child and retained. It - includes all keys (the child's keys) from the keyset file and - signatures generated by this zone's zone keys.</P -></DIV -><DIV -CLASS="sect2" -><H2 -CLASS="sect2" -><A -NAME="AEN996" ->4.8.4. Signing the Zone</A +NAME="AEN972" +>4.8.2. Signing the Zone</A ></H2 ><P >The <B @@ -1418,24 +1320,29 @@ CLASS="command" ><P >Any <TT CLASS="filename" ->signedkey</TT -> files corresponding to - secure subzones should be present, as well as a - <TT -CLASS="filename" ->signedkey</TT -> file for this zone generated by - the parent (if there is one). The zone signer will generate - <TT +>keyset</TT +> files corresponding + to secure subzones should be present. The zone signer will + generate <TT CLASS="literal" ->NXT</TT +>NSEC</TT > and <TT CLASS="literal" ->SIG</TT -> records for - the zone, as well as incorporate the zone key signature from the - parent and indicate the security status at all delegation - points.</P +>RRSIG</TT +> + records for the zone, as well as <TT +CLASS="literal" +>DS</TT +> for + the child zones if <TT +CLASS="literal" +>'-d'</TT +> is specified. + If <TT +CLASS="literal" +>'-d'</TT +> is not specified then DS RRsets for + the secure child zones need to be added manually.</P ><P >The following command signs the zone, assuming it is in a file called <TT @@ -1462,14 +1369,29 @@ CLASS="filename" >named.conf</TT > as the input file for the zone.</P +><P +><B +CLASS="command" +>dnssec-signzone</B +> will also produce a + keyset and dsset files and optionally a dlvset file. These + are used to provide the parent zone administators with the + <TT +CLASS="literal" +>DNSKEYs</TT +> (or their corresponding <TT +CLASS="literal" +>DS</TT +> + records) that are the secure entry point to the zone.</P ></DIV ><DIV CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1012" ->4.8.5. Configuring Servers</A +NAME="AEN994" +>4.8.3. Configuring Servers</A ></H2 ><P >Unlike <SPAN @@ -1496,7 +1418,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN1019" +NAME="AEN1001" >4.9. IPv6 Support in <SPAN CLASS="acronym" >BIND</SPAN @@ -1576,7 +1498,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1037" +NAME="AEN1019" >4.9.1. Address Lookups Using AAAA Records</A ></H2 ><P @@ -1602,7 +1524,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1043" +NAME="AEN1025" >4.9.2. Address to Name Lookups Using Nibble Format</A ></H2 ><P diff --git a/doc/arm/Bv9ARM.ch05.html b/doc/arm/Bv9ARM.ch05.html index 1153c053..7de8b128 100644 --- a/doc/arm/Bv9ARM.ch05.html +++ b/doc/arm/Bv9ARM.ch05.html @@ -84,7 +84,7 @@ CLASS="TOC" ></DT ><DT >5.1. <A -HREF="Bv9ARM.ch05.html#AEN1052" +HREF="Bv9ARM.ch05.html#AEN1034" >The Lightweight Resolver Library</A ></DT ><DT @@ -99,7 +99,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN1052" +NAME="AEN1034" >5.1. The Lightweight Resolver Library</A ></H1 ><P diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html index bec18c57..326d9fb1 100644 --- a/doc/arm/Bv9ARM.ch06.html +++ b/doc/arm/Bv9ARM.ch06.html @@ -94,7 +94,7 @@ HREF="Bv9ARM.ch06.html#Configuration_File_Grammar" ></DT ><DT >6.3. <A -HREF="Bv9ARM.ch06.html#AEN4023" +HREF="Bv9ARM.ch06.html#AEN4009" >Zone File</A ></DT ></DL @@ -149,7 +149,7 @@ file documentation:</P ><DIV CLASS="informaltable" ><A -NAME="AEN1094" +NAME="AEN1076" ></A ><P ></P @@ -765,7 +765,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN1259" +NAME="AEN1241" >6.1.1.1. Syntax</A ></H3 ><PRE @@ -796,7 +796,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN1267" +NAME="AEN1249" >6.1.1.2. Definition and Usage</A ></H3 ><P @@ -910,7 +910,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1298" +NAME="AEN1280" >6.1.2. Comment Syntax</A ></H2 ><P @@ -929,7 +929,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN1303" +NAME="AEN1285" >6.1.2.1. Syntax</A ></H3 ><P @@ -961,7 +961,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN1312" +NAME="AEN1294" >6.1.2.2. Definition and Usage</A ></H3 ><P @@ -1072,7 +1072,7 @@ CLASS="acronym" ><DIV CLASS="informaltable" ><A -NAME="AEN1336" +NAME="AEN1318" ></A ><P ></P @@ -1346,7 +1346,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1419" +NAME="AEN1401" >6.2.1. <B CLASS="command" >acl</B @@ -1393,7 +1393,7 @@ CLASS="command" ><DIV CLASS="informaltable" ><A -NAME="AEN1432" +NAME="AEN1414" ></A ><P ></P @@ -1502,7 +1502,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1463" +NAME="AEN1445" >6.2.3. <B CLASS="command" >controls</B @@ -1824,7 +1824,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1542" +NAME="AEN1524" >6.2.5. <B CLASS="command" >include</B @@ -1844,7 +1844,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1547" +NAME="AEN1529" >6.2.6. <B CLASS="command" >include</B @@ -1873,7 +1873,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1554" +NAME="AEN1536" >6.2.7. <B CLASS="command" >key</B @@ -1907,7 +1907,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1561" +NAME="AEN1543" >6.2.8. <B CLASS="command" >key</B @@ -1995,7 +1995,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1581" +NAME="AEN1563" >6.2.9. <B CLASS="command" >logging</B @@ -2155,7 +2155,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1621" +NAME="AEN1603" >6.2.10. <B CLASS="command" >logging</B @@ -2218,7 +2218,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN1637" +NAME="AEN1619" >6.2.10.1. The <B CLASS="command" >channel</B @@ -2732,7 +2732,7 @@ CLASS="acronym" ><DIV CLASS="informaltable" ><A -NAME="AEN1761" +NAME="AEN1743" ></A ><P ></P @@ -3054,7 +3054,26 @@ CLASS="command" > option has been specified. </P -></TD +> +<P +> The query log entry reports the client's IP address and port number. The +query name, class and type. It also reports whether the Recursion Desired +flag was set (+ if set, - if not set), EDNS was in use (E) or if the +query was signed (S).</P +> +<PRE +CLASS="programlisting" +><TT +CLASS="computeroutput" +>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</TT +> +<TT +CLASS="computeroutput" +>client ::1#62537: query: www.example.net IN AAAA -SE</TT +> +</PRE +> +</TD ></TR ><TR ><TD @@ -3156,7 +3175,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1887" +NAME="AEN1873" >6.2.11. <B CLASS="command" >lwres</B @@ -3253,7 +3272,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1911" +NAME="AEN1897" >6.2.12. <B CLASS="command" >lwres</B @@ -3327,7 +3346,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1930" +NAME="AEN1916" >6.2.13. <B CLASS="command" >masters</B @@ -3388,7 +3407,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1945" +NAME="AEN1931" >6.2.14. <B CLASS="command" >masters</B @@ -3406,7 +3425,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN1950" +NAME="AEN1936" >6.2.15. <B CLASS="command" >options</B @@ -3702,6 +3721,11 @@ CLASS="replaceable" ><I >domain</I ></TT +> trust-anchor <TT +CLASS="replaceable" +><I +>domain</I +></TT >; </SPAN >] [<SPAN @@ -4982,13 +5006,15 @@ CLASS="command" >dnssec-lookaside</B > provides the validator with an alternate method to validate DNSKEY records at the -top of a zone. When set the domain specified by -<B +top of a zone. When a DNSKEY is at or below a domain specified by the +deepest <B CLASS="command" >dnssec-lookaside</B -> is appended to DNSKEY's -name and a DLV record is looked up. If the DLV record validates -a DNSKEY (similarly to the way a DS record does) the DNSKEY RRset is deemed to be trusted. +>, and the normal dnssec validation +has left the key untrusted, the trust-anchor will be append to the key +name and a DLV record will be looked up to see if it can validate the +key. If the DLV record validates a DNSKEY (similarly to the way a DS +record does) the DNSKEY RRset is deemed to be trusted. </P ></DD ><DT @@ -5192,7 +5218,7 @@ processing.</P ><DIV CLASS="informaltable" ><A -NAME="AEN2403" +NAME="AEN2390" ></A ><P ></P @@ -6119,7 +6145,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2682" +NAME="AEN2669" >6.2.16.2. Forwarding</A ></H3 ><P @@ -6187,7 +6213,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2701" +NAME="AEN2688" >6.2.16.3. 6 to 4 Servers</A ></H3 ><P @@ -6409,7 +6435,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2768" +NAME="AEN2755" >6.2.16.5. Interfaces</A ></H3 ><P @@ -6488,7 +6514,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2789" +NAME="AEN2776" >6.2.16.6. Query Address</A ></H3 ><P @@ -6996,7 +7022,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2955" +NAME="AEN2942" >6.2.16.8. Bad UDP Port Lists</A ></H3 ><P @@ -7020,7 +7046,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2960" +NAME="AEN2947" >6.2.16.9. Operating System Resource Limits</A ></H3 ><P @@ -7140,7 +7166,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN2997" +NAME="AEN2984" >6.2.16.10. Server Resource Limits</A ></H3 ><P @@ -7263,7 +7289,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN3038" +NAME="AEN3025" >6.2.16.11. Periodic Task Intervals</A ></H3 ><P @@ -7634,7 +7660,7 @@ CLASS="command" ><DIV CLASS="informaltable" ><A -NAME="AEN3126" +NAME="AEN3113" ></A ><P ></P @@ -8116,7 +8142,7 @@ number is identical to the number in the beginning line.</P ><DIV CLASS="informaltable" ><A -NAME="AEN3270" +NAME="AEN3257" ></A ><P ></P @@ -8650,7 +8676,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN3409" +NAME="AEN3396" >6.2.19. <B CLASS="command" >trusted-keys</B @@ -8725,7 +8751,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN3425" +NAME="AEN3412" >6.2.20. <B CLASS="command" >trusted-keys</B @@ -8827,7 +8853,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN3447" +NAME="AEN3434" >6.2.22. <B CLASS="command" >view</B @@ -9581,7 +9607,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN3621" +NAME="AEN3608" >6.2.24. <B CLASS="command" >zone</B @@ -9592,13 +9618,13 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN3624" +NAME="AEN3611" >6.2.24.1. Zone Types</A ></H3 ><DIV CLASS="informaltable" ><A -NAME="AEN3626" +NAME="AEN3613" ></A ><P ></P @@ -9868,7 +9894,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN3689" +NAME="AEN3676" >6.2.24.2. Class</A ></H3 ><P @@ -9906,7 +9932,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN3699" +NAME="AEN3686" >6.2.24.3. Zone Options</A ></H3 ><P @@ -10048,13 +10074,9 @@ CLASS="command" ></DT ><DD ><P -> This option was used in BIND 8 to restrict the character set of -domain names in master files and/or DNS responses received from the -network. BIND 9 does not restrict the character set of domain names -and does not implement the <B -CLASS="command" ->check-names</B -> option. +> This option is used to restrict the character set and syntax of +certain domain names in master files and/or DNS responses received from the +network. </P ></DD ><DT @@ -10664,7 +10686,7 @@ CLASS="varname" ><DIV CLASS="informaltable" ><A -NAME="AEN3982" +NAME="AEN3968" ></A ><P ></P @@ -10831,7 +10853,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4023" +NAME="AEN4009" >6.3. Zone File</A ></H1 ><DIV @@ -10852,7 +10874,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN4028" +NAME="AEN4014" >6.3.1.1. Resource Records</A ></H3 ><P @@ -10875,7 +10897,7 @@ HREF="Bv9ARM.ch06.html#rrset_ordering" ><DIV CLASS="informaltable" ><A -NAME="AEN4034" +NAME="AEN4020" ></A ><P ></P @@ -10986,7 +11008,7 @@ CLASS="emphasis" ><DIV CLASS="informaltable" ><A -NAME="AEN4066" +NAME="AEN4052" ></A ><P ></P @@ -11511,7 +11533,7 @@ are currently valid in the DNS:</P ><DIV CLASS="informaltable" ><A -NAME="AEN4218" +NAME="AEN4204" ></A ><P ></P @@ -11613,7 +11635,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN4242" +NAME="AEN4228" >6.3.1.2. Textual expression of RRs</A ></H3 ><P @@ -11643,7 +11665,7 @@ knowledge of the typical representation for the data.</P ><DIV CLASS="informaltable" ><A -NAME="AEN4249" +NAME="AEN4235" ></A ><P ></P @@ -11852,7 +11874,7 @@ domain names.</P ><DIV CLASS="informaltable" ><A -NAME="AEN4315" +NAME="AEN4301" ></A ><P ></P @@ -11943,7 +11965,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4343" +NAME="AEN4329" >6.3.2. Discussion of MX Records</A ></H2 ><P @@ -11979,7 +12001,7 @@ pointed to by the CNAME.</P ><DIV CLASS="informaltable" ><A -NAME="AEN4349" +NAME="AEN4335" ></A ><P ></P @@ -12275,7 +12297,7 @@ used in a zone file.</P ><DIV CLASS="informaltable" ><A -NAME="AEN4441" +NAME="AEN4427" ></A ><P ></P @@ -12358,7 +12380,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4464" +NAME="AEN4450" >6.3.4. Inverse Mapping in IPv4</A ></H2 ><P @@ -12385,7 +12407,7 @@ CLASS="optional" ><DIV CLASS="informaltable" ><A -NAME="AEN4469" +NAME="AEN4455" ></A ><P ></P @@ -12465,7 +12487,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4491" +NAME="AEN4477" >6.3.5. Other Zone File Directives</A ></H2 ><P @@ -12490,7 +12512,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN4498" +NAME="AEN4484" >6.3.5.1. The <B CLASS="command" >$ORIGIN</B @@ -12560,7 +12582,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN4518" +NAME="AEN4504" >6.3.5.2. The <B CLASS="command" >$INCLUDE</B @@ -12642,7 +12664,7 @@ CLASS="sect3" ><H3 CLASS="sect3" ><A -NAME="AEN4538" +NAME="AEN4524" >6.3.5.3. The <B CLASS="command" >$TTL</B @@ -12682,7 +12704,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4549" +NAME="AEN4535" >6.3.6. <SPAN CLASS="acronym" >BIND</SPAN @@ -12777,7 +12799,7 @@ CLASS="literal" ><DIV CLASS="informaltable" ><A -NAME="AEN4573" +NAME="AEN4559" ></A ><P ></P diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html index a18ec975..2aa76a89 100644 --- a/doc/arm/Bv9ARM.ch07.html +++ b/doc/arm/Bv9ARM.ch07.html @@ -89,7 +89,7 @@ HREF="Bv9ARM.ch07.html#Access_Control_Lists" ></DT ><DT >7.2. <A -HREF="Bv9ARM.ch07.html#AEN4666" +HREF="Bv9ARM.ch07.html#AEN4652" ><B CLASS="command" >chroot</B @@ -197,7 +197,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4666" +NAME="AEN4652" >7.2. <B CLASS="command" >chroot</B @@ -279,7 +279,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4689" +NAME="AEN4675" >7.2.1. The <B CLASS="command" >chroot</B @@ -355,7 +355,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4707" +NAME="AEN4693" >7.2.2. Using the <B CLASS="command" >setuid</B diff --git a/doc/arm/Bv9ARM.ch08.html b/doc/arm/Bv9ARM.ch08.html index 8c51aa87..c1ee2395 100644 --- a/doc/arm/Bv9ARM.ch08.html +++ b/doc/arm/Bv9ARM.ch08.html @@ -81,17 +81,17 @@ CLASS="TOC" ></DT ><DT >8.1. <A -HREF="Bv9ARM.ch08.html#AEN4728" +HREF="Bv9ARM.ch08.html#AEN4714" >Common Problems</A ></DT ><DT >8.2. <A -HREF="Bv9ARM.ch08.html#AEN4733" +HREF="Bv9ARM.ch08.html#AEN4719" >Incrementing and Changing the Serial Number</A ></DT ><DT >8.3. <A -HREF="Bv9ARM.ch08.html#AEN4738" +HREF="Bv9ARM.ch08.html#AEN4724" >Where Can I Get Help?</A ></DT ></DL @@ -101,7 +101,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4728" +NAME="AEN4714" >8.1. Common Problems</A ></H1 ><DIV @@ -109,7 +109,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4730" +NAME="AEN4716" >8.1.1. It's not working; how can I figure out what's wrong?</A ></H2 ><P @@ -125,7 +125,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4733" +NAME="AEN4719" >8.2. Incrementing and Changing the Serial Number</A ></H1 ><P @@ -154,7 +154,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4738" +NAME="AEN4724" >8.3. Where Can I Get Help?</A ></H1 ><P diff --git a/doc/arm/Bv9ARM.ch09.html b/doc/arm/Bv9ARM.ch09.html index 17082a42..85289d09 100644 --- a/doc/arm/Bv9ARM.ch09.html +++ b/doc/arm/Bv9ARM.ch09.html @@ -74,7 +74,7 @@ CLASS="TOC" ></DT ><DT >A.1. <A -HREF="Bv9ARM.ch09.html#AEN4754" +HREF="Bv9ARM.ch09.html#AEN4740" >Acknowledgments</A ></DT ><DT @@ -97,7 +97,7 @@ CLASS="sect1" ><H1 CLASS="sect1" ><A -NAME="AEN4754" +NAME="AEN4740" >A.1. Acknowledgments</A ></H1 ><DIV @@ -105,7 +105,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN4756" +NAME="AEN4742" >A.1.1. A Brief History of the <SPAN CLASS="acronym" >DNS</SPAN @@ -269,7 +269,7 @@ Unicast address scheme. For more information, see RFC 2374.</P ><DIV CLASS="informaltable" ><A -NAME="AEN4792" +NAME="AEN4778" ></A ><P ></P @@ -488,7 +488,7 @@ VALIGN="MIDDLE" <DIV CLASS="informaltable" ><A -NAME="AEN4861" +NAME="AEN4847" ></A ><P ></P @@ -746,19 +746,19 @@ TARGET="_top" </P ><H3 ><A -NAME="AEN4929" +NAME="AEN4915" >Bibliography</A ></H3 ><H2 CLASS="bibliodiv" ><A -NAME="AEN4930" +NAME="AEN4916" >Standards</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN4932" +NAME="AEN4918" ></A ><P >[RFC974] <SPAN @@ -775,7 +775,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN4939" +NAME="AEN4925" ></A ><P >[RFC1034] <SPAN @@ -792,7 +792,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN4946" +NAME="AEN4932" ></A ><P >[RFC1035] <SPAN @@ -816,7 +816,7 @@ NAME="proposed_standards" ><DIV CLASS="biblioentry" ><A -NAME="AEN4955" +NAME="AEN4941" ></A ><P >[RFC2181] <SPAN @@ -836,7 +836,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN4963" +NAME="AEN4949" ></A ><P >[RFC2308] <SPAN @@ -856,7 +856,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN4971" +NAME="AEN4957" ></A ><P >[RFC1995] <SPAN @@ -876,7 +876,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN4979" +NAME="AEN4965" ></A ><P >[RFC1996] <SPAN @@ -893,7 +893,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN4986" +NAME="AEN4972" ></A ><P >[RFC2136] <SPAN @@ -919,7 +919,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5003" +NAME="AEN4989" ></A ><P >[RFC2845] <SPAN @@ -948,13 +948,13 @@ STYLE="margin-left=0.5in" ><H2 CLASS="bibliodiv" ><A -NAME="AEN5022" +NAME="AEN5008" >Proposed Standards Still Under Development</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN5027" +NAME="AEN5013" ></A ><P >[RFC1886] <SPAN @@ -977,7 +977,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5039" +NAME="AEN5025" ></A ><P >[RFC2065] <SPAN @@ -997,7 +997,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5051" +NAME="AEN5037" ></A ><P >[RFC2137] <SPAN @@ -1014,7 +1014,7 @@ STYLE="margin-left=0.5in" ><H2 CLASS="bibliodiv" ><A -NAME="AEN5059" +NAME="AEN5045" >Other Important RFCs About <SPAN CLASS="acronym" >DNS</SPAN @@ -1023,7 +1023,7 @@ CLASS="acronym" ><DIV CLASS="biblioentry" ><A -NAME="AEN5062" +NAME="AEN5048" ></A ><P >[RFC1535] <SPAN @@ -1043,7 +1043,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5070" +NAME="AEN5056" ></A ><P >[RFC1536] <SPAN @@ -1075,7 +1075,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5091" +NAME="AEN5077" ></A ><P >[RFC1982] <SPAN @@ -1095,13 +1095,13 @@ STYLE="margin-left=0.5in" ><H2 CLASS="bibliodiv" ><A -NAME="AEN5102" +NAME="AEN5088" >Resource Record Types</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN5104" +NAME="AEN5090" ></A ><P >[RFC1183] <SPAN @@ -1130,7 +1130,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5122" +NAME="AEN5108" ></A ><P >[RFC1706] <SPAN @@ -1153,7 +1153,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5134" +NAME="AEN5120" ></A ><P >[RFC2168] <SPAN @@ -1174,7 +1174,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5145" +NAME="AEN5131" ></A ><P >[RFC1876] <SPAN @@ -1201,7 +1201,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5162" +NAME="AEN5148" ></A ><P >[RFC2052] <SPAN @@ -1225,7 +1225,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5174" +NAME="AEN5160" ></A ><P >[RFC2163] <SPAN @@ -1246,7 +1246,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5182" +NAME="AEN5168" ></A ><P >[RFC2230] <SPAN @@ -1266,7 +1266,7 @@ STYLE="margin-left=0.5in" ><H2 CLASS="bibliodiv" ><A -NAME="AEN5190" +NAME="AEN5176" ><SPAN CLASS="acronym" >DNS</SPAN @@ -1275,7 +1275,7 @@ CLASS="acronym" ><DIV CLASS="biblioentry" ><A -NAME="AEN5193" +NAME="AEN5179" ></A ><P >[RFC1101] <SPAN @@ -1295,7 +1295,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5201" +NAME="AEN5187" ></A ><P >[RFC1123] <SPAN @@ -1312,7 +1312,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5208" +NAME="AEN5194" ></A ><P >[RFC1591] <SPAN @@ -1329,7 +1329,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5215" +NAME="AEN5201" ></A ><P >[RFC2317] <SPAN @@ -1352,7 +1352,7 @@ STYLE="margin-left=0.5in" ><H2 CLASS="bibliodiv" ><A -NAME="AEN5229" +NAME="AEN5215" ><SPAN CLASS="acronym" >DNS</SPAN @@ -1361,7 +1361,7 @@ CLASS="acronym" ><DIV CLASS="biblioentry" ><A -NAME="AEN5232" +NAME="AEN5218" ></A ><P >[RFC1537] <SPAN @@ -1381,7 +1381,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5240" +NAME="AEN5226" ></A ><P >[RFC1912] <SPAN @@ -1401,7 +1401,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5248" +NAME="AEN5234" ></A ><P >[RFC2010] <SPAN @@ -1421,7 +1421,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5259" +NAME="AEN5245" ></A ><P >[RFC2219] <SPAN @@ -1444,7 +1444,7 @@ STYLE="margin-left=0.5in" ><H2 CLASS="bibliodiv" ><A -NAME="AEN5271" +NAME="AEN5257" >Other <SPAN CLASS="acronym" >DNS</SPAN @@ -1453,7 +1453,7 @@ CLASS="acronym" ><DIV CLASS="biblioentry" ><A -NAME="AEN5277" +NAME="AEN5263" ></A ><P >[RFC1464] <SPAN @@ -1470,7 +1470,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5284" +NAME="AEN5270" ></A ><P >[RFC1713] <SPAN @@ -1490,7 +1490,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5292" +NAME="AEN5278" ></A ><P >[RFC1794] <SPAN @@ -1510,7 +1510,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5300" +NAME="AEN5286" ></A ><P >[RFC2240] <SPAN @@ -1527,7 +1527,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5307" +NAME="AEN5293" ></A ><P >[RFC2345] <SPAN @@ -1550,7 +1550,7 @@ STYLE="margin-left=0.5in" ><DIV CLASS="biblioentry" ><A -NAME="AEN5321" +NAME="AEN5307" ></A ><P >[RFC2352] <SPAN @@ -1567,13 +1567,13 @@ STYLE="margin-left=0.5in" ><H2 CLASS="bibliodiv" ><A -NAME="AEN5328" +NAME="AEN5314" >Obsolete and Unimplemented Experimental RRs</A ></H2 ><DIV CLASS="biblioentry" ><A -NAME="AEN5330" +NAME="AEN5316" ></A ><P >[RFC1712] <SPAN @@ -1624,7 +1624,7 @@ CLASS="sect2" ><H2 CLASS="sect2" ><A -NAME="AEN5351" +NAME="AEN5337" >A.3.3. Other Documents About <SPAN CLASS="acronym" >BIND</SPAN @@ -1634,13 +1634,13 @@ CLASS="acronym" ></P ><H3 ><A -NAME="AEN5355" +NAME="AEN5341" >Bibliography</A ></H3 ><DIV CLASS="biblioentry" ><A -NAME="AEN5356" +NAME="AEN5342" ></A ><P ><SPAN diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html index 60ec2388..7c5c9f03 100644 --- a/doc/arm/Bv9ARM.html +++ b/doc/arm/Bv9ARM.html @@ -292,34 +292,24 @@ HREF="Bv9ARM.ch04.html#DNSSEC" ><DL ><DT >4.8.1. <A -HREF="Bv9ARM.ch04.html#AEN951" +HREF="Bv9ARM.ch04.html#AEN952" >Generating Keys</A ></DT ><DT >4.8.2. <A -HREF="Bv9ARM.ch04.html#AEN971" ->Creating a Keyset</A -></DT -><DT ->4.8.3. <A -HREF="Bv9ARM.ch04.html#AEN983" ->Signing the Child's Keyset</A -></DT -><DT ->4.8.4. <A -HREF="Bv9ARM.ch04.html#AEN996" +HREF="Bv9ARM.ch04.html#AEN972" >Signing the Zone</A ></DT ><DT ->4.8.5. <A -HREF="Bv9ARM.ch04.html#AEN1012" +>4.8.3. <A +HREF="Bv9ARM.ch04.html#AEN994" >Configuring Servers</A ></DT ></DL ></DD ><DT >4.9. <A -HREF="Bv9ARM.ch04.html#AEN1019" +HREF="Bv9ARM.ch04.html#AEN1001" >IPv6 Support in <SPAN CLASS="acronym" >BIND</SPAN @@ -329,12 +319,12 @@ CLASS="acronym" ><DL ><DT >4.9.1. <A -HREF="Bv9ARM.ch04.html#AEN1037" +HREF="Bv9ARM.ch04.html#AEN1019" >Address Lookups Using AAAA Records</A ></DT ><DT >4.9.2. <A -HREF="Bv9ARM.ch04.html#AEN1043" +HREF="Bv9ARM.ch04.html#AEN1025" >Address to Name Lookups Using Nibble Format</A ></DT ></DL @@ -353,7 +343,7 @@ CLASS="acronym" ><DL ><DT >5.1. <A -HREF="Bv9ARM.ch05.html#AEN1052" +HREF="Bv9ARM.ch05.html#AEN1034" >The Lightweight Resolver Library</A ></DT ><DT @@ -387,7 +377,7 @@ HREF="Bv9ARM.ch06.html#address_match_lists" ></DT ><DT >6.1.2. <A -HREF="Bv9ARM.ch06.html#AEN1298" +HREF="Bv9ARM.ch06.html#AEN1280" >Comment Syntax</A ></DT ></DL @@ -401,7 +391,7 @@ HREF="Bv9ARM.ch06.html#Configuration_File_Grammar" ><DL ><DT >6.2.1. <A -HREF="Bv9ARM.ch06.html#AEN1419" +HREF="Bv9ARM.ch06.html#AEN1401" ><B CLASS="command" >acl</B @@ -418,7 +408,7 @@ Usage</A ></DT ><DT >6.2.3. <A -HREF="Bv9ARM.ch06.html#AEN1463" +HREF="Bv9ARM.ch06.html#AEN1445" ><B CLASS="command" >controls</B @@ -434,7 +424,7 @@ CLASS="command" ></DT ><DT >6.2.5. <A -HREF="Bv9ARM.ch06.html#AEN1542" +HREF="Bv9ARM.ch06.html#AEN1524" ><B CLASS="command" >include</B @@ -442,7 +432,7 @@ CLASS="command" ></DT ><DT >6.2.6. <A -HREF="Bv9ARM.ch06.html#AEN1547" +HREF="Bv9ARM.ch06.html#AEN1529" ><B CLASS="command" >include</B @@ -450,7 +440,7 @@ CLASS="command" ></DT ><DT >6.2.7. <A -HREF="Bv9ARM.ch06.html#AEN1554" +HREF="Bv9ARM.ch06.html#AEN1536" ><B CLASS="command" >key</B @@ -458,7 +448,7 @@ CLASS="command" ></DT ><DT >6.2.8. <A -HREF="Bv9ARM.ch06.html#AEN1561" +HREF="Bv9ARM.ch06.html#AEN1543" ><B CLASS="command" >key</B @@ -466,7 +456,7 @@ CLASS="command" ></DT ><DT >6.2.9. <A -HREF="Bv9ARM.ch06.html#AEN1581" +HREF="Bv9ARM.ch06.html#AEN1563" ><B CLASS="command" >logging</B @@ -474,7 +464,7 @@ CLASS="command" ></DT ><DT >6.2.10. <A -HREF="Bv9ARM.ch06.html#AEN1621" +HREF="Bv9ARM.ch06.html#AEN1603" ><B CLASS="command" >logging</B @@ -482,7 +472,7 @@ CLASS="command" ></DT ><DT >6.2.11. <A -HREF="Bv9ARM.ch06.html#AEN1887" +HREF="Bv9ARM.ch06.html#AEN1873" ><B CLASS="command" >lwres</B @@ -490,7 +480,7 @@ CLASS="command" ></DT ><DT >6.2.12. <A -HREF="Bv9ARM.ch06.html#AEN1911" +HREF="Bv9ARM.ch06.html#AEN1897" ><B CLASS="command" >lwres</B @@ -498,7 +488,7 @@ CLASS="command" ></DT ><DT >6.2.13. <A -HREF="Bv9ARM.ch06.html#AEN1930" +HREF="Bv9ARM.ch06.html#AEN1916" ><B CLASS="command" >masters</B @@ -506,7 +496,7 @@ CLASS="command" ></DT ><DT >6.2.14. <A -HREF="Bv9ARM.ch06.html#AEN1945" +HREF="Bv9ARM.ch06.html#AEN1931" ><B CLASS="command" >masters</B @@ -514,7 +504,7 @@ CLASS="command" ></DT ><DT >6.2.15. <A -HREF="Bv9ARM.ch06.html#AEN1950" +HREF="Bv9ARM.ch06.html#AEN1936" ><B CLASS="command" >options</B @@ -546,7 +536,7 @@ CLASS="command" ></DT ><DT >6.2.19. <A -HREF="Bv9ARM.ch06.html#AEN3409" +HREF="Bv9ARM.ch06.html#AEN3396" ><B CLASS="command" >trusted-keys</B @@ -554,7 +544,7 @@ CLASS="command" ></DT ><DT >6.2.20. <A -HREF="Bv9ARM.ch06.html#AEN3425" +HREF="Bv9ARM.ch06.html#AEN3412" ><B CLASS="command" >trusted-keys</B @@ -571,7 +561,7 @@ CLASS="command" ></DT ><DT >6.2.22. <A -HREF="Bv9ARM.ch06.html#AEN3447" +HREF="Bv9ARM.ch06.html#AEN3434" ><B CLASS="command" >view</B @@ -588,7 +578,7 @@ Statement Grammar</A ></DT ><DT >6.2.24. <A -HREF="Bv9ARM.ch06.html#AEN3621" +HREF="Bv9ARM.ch06.html#AEN3608" ><B CLASS="command" >zone</B @@ -598,7 +588,7 @@ CLASS="command" ></DD ><DT >6.3. <A -HREF="Bv9ARM.ch06.html#AEN4023" +HREF="Bv9ARM.ch06.html#AEN4009" >Zone File</A ></DT ><DD @@ -610,7 +600,7 @@ HREF="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them" ></DT ><DT >6.3.2. <A -HREF="Bv9ARM.ch06.html#AEN4343" +HREF="Bv9ARM.ch06.html#AEN4329" >Discussion of MX Records</A ></DT ><DT @@ -620,17 +610,17 @@ HREF="Bv9ARM.ch06.html#Setting_TTLs" ></DT ><DT >6.3.4. <A -HREF="Bv9ARM.ch06.html#AEN4464" +HREF="Bv9ARM.ch06.html#AEN4450" >Inverse Mapping in IPv4</A ></DT ><DT >6.3.5. <A -HREF="Bv9ARM.ch06.html#AEN4491" +HREF="Bv9ARM.ch06.html#AEN4477" >Other Zone File Directives</A ></DT ><DT >6.3.6. <A -HREF="Bv9ARM.ch06.html#AEN4549" +HREF="Bv9ARM.ch06.html#AEN4535" ><SPAN CLASS="acronym" >BIND</SPAN @@ -660,7 +650,7 @@ HREF="Bv9ARM.ch07.html#Access_Control_Lists" ></DT ><DT >7.2. <A -HREF="Bv9ARM.ch07.html#AEN4666" +HREF="Bv9ARM.ch07.html#AEN4652" ><B CLASS="command" >chroot</B @@ -674,7 +664,7 @@ UNIX servers)</A ><DL ><DT >7.2.1. <A -HREF="Bv9ARM.ch07.html#AEN4689" +HREF="Bv9ARM.ch07.html#AEN4675" >The <B CLASS="command" >chroot</B @@ -682,7 +672,7 @@ CLASS="command" ></DT ><DT >7.2.2. <A -HREF="Bv9ARM.ch07.html#AEN4707" +HREF="Bv9ARM.ch07.html#AEN4693" >Using the <B CLASS="command" >setuid</B @@ -706,26 +696,26 @@ HREF="Bv9ARM.ch08.html" ><DL ><DT >8.1. <A -HREF="Bv9ARM.ch08.html#AEN4728" +HREF="Bv9ARM.ch08.html#AEN4714" >Common Problems</A ></DT ><DD ><DL ><DT >8.1.1. <A -HREF="Bv9ARM.ch08.html#AEN4730" +HREF="Bv9ARM.ch08.html#AEN4716" >It's not working; how can I figure out what's wrong?</A ></DT ></DL ></DD ><DT >8.2. <A -HREF="Bv9ARM.ch08.html#AEN4733" +HREF="Bv9ARM.ch08.html#AEN4719" >Incrementing and Changing the Serial Number</A ></DT ><DT >8.3. <A -HREF="Bv9ARM.ch08.html#AEN4738" +HREF="Bv9ARM.ch08.html#AEN4724" >Where Can I Get Help?</A ></DT ></DL @@ -739,14 +729,14 @@ HREF="Bv9ARM.ch09.html" ><DL ><DT >A.1. <A -HREF="Bv9ARM.ch09.html#AEN4754" +HREF="Bv9ARM.ch09.html#AEN4740" >Acknowledgments</A ></DT ><DD ><DL ><DT >A.1.1. <A -HREF="Bv9ARM.ch09.html#AEN4756" +HREF="Bv9ARM.ch09.html#AEN4742" >A Brief History of the <SPAN CLASS="acronym" >DNS</SPAN @@ -793,7 +783,7 @@ HREF="Bv9ARM.ch09.html#internet_drafts" ></DT ><DT >A.3.3. <A -HREF="Bv9ARM.ch09.html#AEN5351" +HREF="Bv9ARM.ch09.html#AEN5337" >Other Documents About <SPAN CLASS="acronym" >BIND</SPAN diff --git a/doc/draft/draft-ietf-dnsext-dns-threats-06.txt b/doc/draft/draft-ietf-dnsext-dns-threats-07.txt index 6540f0de..15217dad 100644 --- a/doc/draft/draft-ietf-dnsext-dns-threats-06.txt +++ b/doc/draft/draft-ietf-dnsext-dns-threats-07.txt @@ -1,10 +1,10 @@ Network Working Group D. Atkins -draft-ietf-dnsext-dns-threats-06.txt IHTFP Consulting +draft-ietf-dnsext-dns-threats-07.txt IHTFP Consulting R. Austein ISC - February 2004 + April 2004 Threat Analysis of the Domain Name System @@ -51,9 +51,9 @@ Abstract -Atkins & Austein Expires 21 August 2004 [Page 1] +Atkins & Austein Expires 9 October 2004 [Page 1] -draft-ietf-dnsext-dns-threats-06.txt February 2004 +draft-ietf-dnsext-dns-threats-07.txt April 2004 1. Introduction @@ -107,9 +107,9 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 -Atkins & Austein Expires 21 August 2004 [Page 2] +Atkins & Austein Expires 9 October 2004 [Page 2] -draft-ietf-dnsext-dns-threats-06.txt February 2004 +draft-ietf-dnsext-dns-threats-07.txt April 2004 [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308], @@ -163,9 +163,9 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 -Atkins & Austein Expires 21 August 2004 [Page 3] +Atkins & Austein Expires 9 October 2004 [Page 3] -draft-ietf-dnsext-dns-threats-06.txt February 2004 +draft-ietf-dnsext-dns-threats-07.txt April 2004 heavily used name servers (such as the servers for the root zone), @@ -219,9 +219,9 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 -Atkins & Austein Expires 21 August 2004 [Page 4] +Atkins & Austein Expires 9 October 2004 [Page 4] -draft-ietf-dnsext-dns-threats-06.txt February 2004 +draft-ietf-dnsext-dns-threats-07.txt April 2004 QTYPEs for which a resolver might be querying, this leaves the @@ -248,24 +248,41 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 with a recursing name server that does perform DNSSEC signature checking. -2.3. Name Games +2.3. Name Chaining Perhaps the most interesting class of DNS-specific threats are the - name-based attacks. There are several variations within this class, - sometimes called "cache poisoning" or "fake authority" attacks. What - all of these attacks have in common is that they all involve DNS RRs - whose RDATA portion (right hand side) includes a DNS name. Any such - RR is, at least in principle, a hook that lets an attacker feed bad - data into a victim's cache, thus potentially subverting subsequent - decisions based on DNS names. + name chaining attacks. These are a subset of a larger class of name- + based attacks, sometimes called "cache poisoning" attacks. Most + name-based attacks can be at least partially mitigated by the long- + standing defense of checking RRs in response messages for relevance + to the original query, but such defenses do not catch name chaining + attacks. There are several variations on the basic attack, but what + they all have in common is that they all involve DNS RRs whose RDATA + portion (right hand side) includes a DNS name (or, in a few cases, + something that is not a DNS name but which directly maps to a DNS + name). Any such RR is, at least in principle, a hook that lets an + attacker feed bad data into a victim's cache, thus potentially + subverting subsequent decisions based on DNS names. The worst examples in this class of RRs are CNAME, NS, and DNAME RRs, because they can redirect a victim's query to a location of the attacker's choosing. RRs like MX and SRV are somewhat less dangerous, but in principle they can also be used to trigger further - lookups at a location of the attacker's choosing. + lookups at a location of the attacker's choosing. Address RR types + such as A or AAAA don't have DNS names in their RDATA, but since the + IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of + IPv4 and IPv6 addresses, these record types can also be used in a - The general form of a name-based attack is something like this: + + +Atkins & Austein Expires 9 October 2004 [Page 5] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + name chaining attack. + + The general form of a name chaining attack is something like this: - Victim issues a query, perhaps at the instigation of the attacker or some third party; in some cases the query itself may be @@ -273,13 +290,6 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 using this query as a means to inject false information about some other name). - - -Atkins & Austein Expires 21 August 2004 [Page 5] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - - Attacker injects response, whether via packet interception, query guessing, or by being a legitimate name server that's involved at some point in the process of answering the query that the victim @@ -298,19 +308,19 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 Any attacker who can insert resource records into a victim's cache can almost certainly do some kind of damage, so there are cache - poisoning attacks which are not name-based attacks in the sense - discussed here. However, in the case of name-based attacks, the + poisoning attacks which are not name chaining attacks in the sense + discussed here. However, in the case of name chaining attacks, the cause and effect relationship between the initial attack and the eventual result may be significantly more complex than in the other - forms of cache poisoning, so name-based attacks merit special + forms of cache poisoning, so name chaining attacks merit special attention. - The common thread in all of the name-based attacks is that response - messages allow the attacker to introduce arbitrary DNS names of the - attacker's choosing and provide further information that the attacker - claims is associated with those names; unless the victim has better - knowledge of the data associated with those names, the victim is - going to have a hard time defending against this class of attacks. + The common thread in all of the name chaining attacks is that + response messages allow the attacker to introduce arbitrary DNS names + of the attacker's choosing and provide further information that the + attacker claims is associated with those names; unless the victim has + better knowledge of the data associated with those names, the victim + is going to have a hard time defending against this class of attacks. This class of attack is particularly insidious given that it's quite easy for an attacker to provoke a victim into querying for a @@ -318,6 +328,14 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail to the victim. If the victim's mail reading program attempts to follow such a link, the result will be a DNS query for a name chosen + + + +Atkins & Austein Expires 9 October 2004 [Page 6] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + by the attacker. DNSSEC should provide a good defense against most (all?) variations @@ -328,20 +346,12 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 injected the data had access to an allegedly secret key whose corresponding public key appears at an expected location in the DNS name space with an expected chain of parental signatures that start - - - -Atkins & Austein Expires 21 August 2004 [Page 6] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - with a public key of which the resolver has prior knowledge). DNSSEC signatures do not cover glue records, so there's still a - possibility of a name-based attack involving glue, but with DNSSEC it - is possible to detect the attack by temporarily accepting the glue in - order to fetch the signed authoritative version of the same data, + possibility of a name chaining attack involving glue, but with DNSSEC + it is possible to detect the attack by temporarily accepting the glue + in order to fetch the signed authoritative version of the same data, then checking the signatures on the authoritative version. 2.4. Betrayal By Trusted Server @@ -374,6 +384,14 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 prevent the client host from being able to run an iterative resolver even if the owner of the client machine is willing and able to do so. Thus, while the initial source of this problem is not a DNS protocol + + + +Atkins & Austein Expires 9 October 2004 [Page 7] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + attack per se, this sort of betrayal is a threat to DNS clients, and simply switching to a different recursive name server is not an adequate defense. @@ -384,14 +402,6 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 attacker. The defense against this is the same as with a packet interception attack: the resolver must either check DNSSEC signatures itself or use TSIG (or equivalent) to authenticate the server that it - - - -Atkins & Austein Expires 21 August 2004 [Page 7] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - has chosen to trust. Note that use of TSIG does not by itself guarantee that a name server is at all trustworthy: all TSIG can do is help a resolver protect its communication with a name server that @@ -430,6 +440,14 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 Much discussion has taken place over the question of authenticated denial of domain names. The particular question is whether there is a requirement for authenticating the non-existence of a name. The + + + +Atkins & Austein Expires 9 October 2004 [Page 8] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + issue is whether the resolver should be able to detect when an attacker removes RRs from a response. @@ -440,14 +458,6 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 might be considered a problem. The question remains: how serious is this threat? Clearly the threat does exist; general paranoia says that some day it'll be on the front page of some major newspaper, - - - -Atkins & Austein Expires 21 August 2004 [Page 8] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - even if we cannot conceive of a plausible scenario involving this attack today. This implies that some mitigation of this risk is required. @@ -486,6 +496,14 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 applicable). Note that this makes the wildcard mechanisms dependent upon the + + + +Atkins & Austein Expires 9 October 2004 [Page 9] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + authenticated denial mechanism described in the previous section. DNSSEC includes mechanisms along the lines described above, which @@ -496,14 +514,6 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 DNSSEC has some problems of its own: - - - -Atkins & Austein Expires 21 August 2004 [Page 9] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - - DNSSEC is complex to implement, and includes some nasty edge cases at the zone cuts that require very careful coding. Testbed experience to date suggests that trivial zone configuration errors @@ -542,6 +552,14 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 the validating resolver and the entity creating the DNSSEC signatures. Prior to DNSSEC, all time-related actions in DNS could be performed by a machine that only knew about "elapsed" or + + + +Atkins & Austein Expires 9 October 2004 [Page 10] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + "relative" time. Because the validity period of a DNSSEC signature is based on "absolute" time, a validating resolver must have the same concept of absolute time as the zone signer in order to @@ -553,13 +571,6 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 generating signatures whose validity period does not match what the signer intended. - - -Atkins & Austein Expires 21 August 2004 [Page 10] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - - The possible existence of wildcard RRs in a zone complicates the authenticated denial mechanism considerably. For most of the decade that DNSSEC has been under development these issues were @@ -598,6 +609,13 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 There are, however, other potential problems at the boundaries where DNS interacts with other protocols. + + +Atkins & Austein Expires 9 October 2004 [Page 11] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + 4.2. Securing DNS Dynamic Update DNS dynamic update opens a number of potential problems when combined @@ -608,14 +626,6 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 limited or closed environment such as a DHCP server updating a local DNS name server. - - - -Atkins & Austein Expires 21 August 2004 [Page 11] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - Major issues arise when trying to use dynamic update on a secure zone. TSIG can similarly be used in a limited fashion to authenticate the client to the server, but TSIG only protects DNS @@ -651,6 +661,17 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 Scaling properties of the key management problem here are a particular concern that needs more study. + + + + + + +Atkins & Austein Expires 9 October 2004 [Page 12] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + 4.3. Securing DNS Zone Replication As discussed in previous sections, DNSSEC per se attempts to provide @@ -664,14 +685,6 @@ draft-ietf-dnsext-dns-threats-06.txt February 2004 security", but still does not provide object security for complete zones, so the trust relationships involved in zone transfer are still very much a hop-by-hop matter of name server operators trusting other - - - -Atkins & Austein Expires 21 August 2004 [Page 12] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - name server operators, rather than an end-to-end matter of name server operators trusting zone administrators. @@ -707,6 +720,14 @@ Acknowledgments Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, and any other + + + +Atkins & Austein Expires 9 October 2004 [Page 13] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose names and contributions the authors have forgotten, none of whom are responsible for what the authors did with their ideas. @@ -721,13 +742,6 @@ Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, November 1987. - - -Atkins & Austein Expires 21 August 2004 [Page 13] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - [RFC1035] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987. @@ -762,6 +776,14 @@ Informative References Board, "Guidelines for Writing RFC Text on Security Considerations", RFC 3552, July 2003. + + + +Atkins & Austein Expires 9 October 2004 [Page 14] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + [Bellovin95] Bellovin, S., "Using the Domain Name System for System Break-Ins", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995. @@ -776,14 +798,6 @@ Informative References [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995. - - - -Atkins & Austein Expires 21 August 2004 [Page 14] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - Authors' addresses: Derek Atkins @@ -818,6 +832,14 @@ Intellectual Property Statement be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any + + + +Atkins & Austein Expires 9 October 2004 [Page 15] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + 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 @@ -832,14 +854,6 @@ Full Copyright Statement 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 - - - -Atkins & Austein Expires 21 August 2004 [Page 15] - -draft-ietf-dnsext-dns-threats-06.txt February 2004 - - 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 @@ -877,19 +891,5 @@ Acknowledgement - - - - - - - - - - - - - - -Atkins & Austein Expires 21 August 2004 [Page 16] +Atkins & Austein Expires 9 October 2004 [Page 16] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt index 8097d634..5ac9cba5 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt @@ -1,1401 +1,1513 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: August 16, 2004 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - February 16, 2004 - - - DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-09 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 16, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - The Domain Name System Security Extensions (DNSSEC) add data origin - authentication and data integrity to the Domain Name System. This - document introduces these extensions, and describes their - capabilities and limitations. This document also discusses the - services that the DNS security extensions do and do not provide. - - - -Arends, et al. Expires August 16, 2004 [Page 1] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - Last, this document describes the interrelationships between the - group of documents that collectively describe DNSSEC. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 - 3. Services Provided by DNS Security . . . . . . . . . . . . . . 7 - 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 7 - 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 8 - 4. Services Not Provided by DNS Security . . . . . . . . . . . . 10 - 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 11 - 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 12 - 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 7.1 TTL values vs. RRSIG validity period . . . . . . . . . . . . . 13 - 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13 - 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14 - 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 - Normative References . . . . . . . . . . . . . . . . . . . . . 20 - Informative References . . . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 - Intellectual Property and Copyright Statements . . . . . . . . 24 - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 2] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -1. Introduction - - This document introduces the Domain Name System Security Extensions - (DNSSEC). This document and its two companion documents - ([I-D.ietf-dnsext-dnssec-records] and - [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the - security extensions defined in RFC 2535 [RFC2535] and its - predecessors. These security extensions consist of a set of new - resource record types and modifications to the existing DNS protocol - [RFC1035]. The new records and protocol modifications are not fully - described in this document, but are described in a family of - documents outlined in Section 9. Section 3 and Section 4 describe the - capabilities and limitations of the security extensions in greater - detail. Section 5, Section 6, Section 7, and Section 8 discuss the - effect that these security extensions will have on resolvers, stub - resolvers, zones and name servers. - - This document and its two companions update and obsolete RFCs 2535 - [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445 - [RFC3445], as well as several works in progress: "Redefinition of the - AD bit" [RFC3655], "Legacy Resolver Compatibility for Delegation - Signer" [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation - Signer Resource Record" [RFC3658]. This document set also updates, - but does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 - [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597 [RFC3597]. - - The DNS security extensions provide origin authentication and - integrity protection for DNS data, as well as a means of public key - distribution. These extensions do not provide confidentiality. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 3] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -2. Definitions of Important DNSSEC Terms - - This section defines a number of terms used in this document set. - Since this is intended to be useful as a reference while reading the - rest of the document set, first-time readers may wish to skim this - section quickly, read the rest of this document, then come back to - this section. - - authentication chain: an alternating sequence of DNSKEY RRsets and DS - RRsets forms a chain of signed data, with each link in the chain - vouching for the next. A DNSKEY RR is used to verify the - signature covering a DS RR and allows the DS RR to be - authenticated. The DS RR contains a hash of another DNSKEY RR and - this new DNSKEY RR is authenticated by matching the hash in the DS - RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset - and, in turn, some DNSKEY RR in this set may be used to - authenticate another DS RR and so forth until the chain finally - ends with a DNSKEY RR which signs the desired DNS data. For - example, the root DNSKEY RRset can be used to authenticate the DS - RRset for "example." The "example." DS RRset contains a hash that - matches some "example." DNSKEY and this DNSKEY signs the - "example." DNSKEY RRset. Private key counterparts of the - "example." DNSKEY RRset sign data records such as "www.example." - as well as DS RRs for delegations such as "subzone.example." - - authentication key: A public key which a security-aware resolver has - verified and can therefore use to authenticate data. A - security-aware resolver can obtain authentication keys in three - ways. First, the resolver is generally preconfigured to know - about at least one public key. This preconfigured data is usually - either the public key itself or a hash of the key as found in the - DS RR. Second, the resolver may use an authenticated public key - to verify a DS RR and its associated DNSKEY RR. Third, the - resolver may be able to determine that a new key has been signed - by another key which the resolver has verified. Note that the - resolver must always be guided by local policy when deciding - whether to authenticate a new key, even if the local policy is - simply to authenticate any new key for which the resolver is able - verify the signature. - - delegation point: Term used to describe the name at the parental side - of a zone cut. That is, the delegation point for "foo.example" - would be the foo.example node in the "example" zone (as opposed to - the zone apex of the "foo.example" zone). - - island of security: Term used to describe a signed, delegated zone - that does not have an authentication chain from its delegating - parent. That is, there is no DS RR with the island's public key - - - -Arends, et al. Expires August 16, 2004 [Page 4] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - in its delegating parent zone (see - [I-D.ietf-dnsext-dnssec-records]). An island of security is served - by a security-aware nameserver and may provide authentication - chains to any delegated child zones. Responses from an island of - security or its descendents can only be authenticated if its zone - key can be authenticated by some trusted means out of band from - the DNS protocol. - - key signing key: An authentication key which is used to sign one or - more other authentication keys for a given zone. Typically, a key - signing key will sign a zone signing key, which in turn will sign - other zone data. Local policy may require the zone signing key to - be changed frequently, while the key signing key may have a longer - validity period in order to provide a more stable secure entry - point into the zone. Designating an authentication key as a key - signing key is purely an operational issue: DNSSEC validation does - not distinguish between key signing keys and other DNSSEC - authentication keys. Key signing keys are discussed in more - detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: zone - signing key. - - non-validating security-aware stub resolver: A security-aware stub - resolver which trusts one or more security-aware recursive name - servers to perform most of the tasks discussed in this document - set on its behalf. In particular, a non-validating security-aware - stub resolver is an entity which sends DNS queries, receives DNS - responses, and is capable of establishing an appropriately secured - channel to a security-aware recursive name server which will - provide these services on behalf of the security-aware stub - resolver. See also: security-aware stub resolver, validating - security-aware stub resolver. - - non-validating stub resolver: A less tedious term for a - non-validating security-aware stub resolver. - - security-aware name server: An entity acting in the role of a name - server (defined in section 2.4 of [RFC1034]) which understands the - DNS security extensions defined in this document set. In - particular, a security-aware name server is an entity which - receives DNS queries, sends DNS responses, supports the EDNS0 - [RFC2671] message size extension and the DO bit [RFC3225], and - supports the RR types and message header bits defined in this - document set. - - security-aware recursive name server: An entity which acts in both - the security-aware name server and security-aware resolver roles. - A more cumbersome equivalent phrase would be "a security-aware - name server which offers recursive service". - - - -Arends, et al. Expires August 16, 2004 [Page 5] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - security-aware resolver: An entity acting in the role of a resolver - (defined in section 2.4 of [RFC1034]) which understands the DNS - security extensions defined in this document set. In particular, - a security-aware resolver is an entity which sends DNS queries, - receives DNS responses, supports the EDNS0 [RFC2671] message size - extension and the DO bit [RFC3225], and is capable of using the RR - types and message header bits defined in this document set to - provide DNSSEC services. - - security-aware stub resolver: An entity acting in the role of a stub - resolver (defined in section 5.3.1 of [RFC1034]) which has enough - of an understanding the DNS security extensions defined in this - document set to provide additional services not available from a - security-oblivious stub resolver. Security-aware stub resolvers - may be either "validating" or "non-validating" depending on - whether the stub resolver attempts to verify DNSSEC signatures on - its own or trusts a friendly security-aware name server to do so. - See also: validating stub resolver, non-validating stub resolver. - - security-oblivious <anything>: An <anything> which is not - "security-aware". - - signed zone: A zone whose RRsets are signed and which contains - properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS - records. - - unsigned zone: A zone which is not signed. - - validating security-aware stub resolver: A security-aware resolver - which operates sends queries in recursive mode but which performs - signature validation on its own rather than just blindly trusting - a friendly security-aware recursive name server. See also: - security-aware stub resolver, non-validating security-aware stub - resolver. - - validating stub resolver: A less tedious term for a validating - security-aware stub resolver. - - zone signing key: An authentication key which is used to sign a zone. - See key signing key, above. Typically a zone signing key will be - part of the same DNSKEY RRset as the key signing key which signs - it, but is used for a slightly different purpose and may differ - from the key signing key in other ways, such as validity lifetime. - Designating an authentication key as a zone signing key is purely - an operational issue: DNSSEC validation does not distinguish - between zone signing keys and other DNSSEC authentication keys. - See also: key signing key. - - - - -Arends, et al. Expires August 16, 2004 [Page 6] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -3. Services Provided by DNS Security - - The Domain Name System (DNS) security extensions provide origin - authentication and integrity assurance services for DNS data, - including mechanisms for authenticated denial of existence of DNS - data. These mechanisms are described below. - - These mechanisms require changes to the DNS protocol. DNSSEC adds - four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two - new message header bits (CD and AD). In order to support the larger - DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also - requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support - for the DO bit [RFC3225], so that a security-aware resolver can - indicate in its queries that it wishes to receive DNSSEC RRs in - response messages. - - These services protect against most of the threats to the Domain Name - System described in [I-D.ietf-dnsext-dns-threats]. - -3.1 Data Origin Authentication and Data Integrity - - DNSSEC provides authentication by associating cryptographically - generated digital signatures with DNS RRsets. These digital - signatures are stored in a new resource record, the RRSIG record. - Typically, there will be a single private key that signs a zone's - data, but multiple keys are possible: for example, there may be keys - for each of several different digital signature algorithms. If a - security-aware resolver reliably learns a zone's public key, it can - authenticate that zone's signed data. An important DNSSEC concept is - that the key that signs a zone's data is associated with the zone - itself and not with the zone's authoritative name servers (public - keys for DNS transaction authentication mechanisms may also appear in - zones, as described in [RFC2931], but DNSSEC itself is concerned with - object security of DNS data, not channel security of DNS - transactions). - - A security-aware resolver can learn a zone's public key either by - having the key preconfigured into the resolver or by normal DNS - resolution. To allow the latter, public keys are stored in a new - type of resource record, the DNSKEY RR. Note that the private keys - used to sign zone data must be kept secure, and should be stored - offline when practical to do so. To discover a public key reliably - via DNS resolution, the target key itself needs to be signed by - either a preconfigured authentication key or another key that has - been authenticated previously. Security-aware resolvers authenticate - zone information by forming an authentication chain from a newly - learned public key back to a previously known authentication public - key, which in turn either must have been preconfigured into the - - - -Arends, et al. Expires August 16, 2004 [Page 7] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - resolver or must have been learned and verified previously. - Therefore, the resolver must be configured with at least one public - key or hash of a public key: if the preconfigured key is a zone - signing key, then it will authenticate the associated zone; if the - preconfigured key is a key signing key, it will authenticate a zone - signing key. If the resolver has been preconfigured with the hash of - a key rather than the key itself, the resolver may need to obtain the - key via a DNS query. To help security-aware resolvers establish this - authentication chain, security-aware name servers attempt to send the - signature(s) needed to authenticate a zone's public key in the DNS - reply message along with the public key itself, provided there is - space available in the message. - - The Delegation Signer (DS) RR type simplifies some of the - administrative tasks involved in signing delegations across - organizational boundaries. The DS RRset resides at a delegation - point in a parent zone and indicates the key or keys used by the - delegated child zone to self-sign the DNSKEY RRset at the child - zone's apex. The child zone, in turn, uses one or more of the keys - in this DNSKEY RRset to sign its zone data. The typical - authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where - "*" denotes zero or more DS->DNSKEY subchains. DNSSEC permits more - complex authentication chains, such as additional layers of DNSKEY - RRs signing other DNSKEY RRs within a zone. - - A security-aware resolver normally constructs this authentication - chain from the root of the DNS hierarchy down to the leaf zones based - on preconfigured knowledge of the public key for the root. Local - policy, however, may also allow a security-aware resolver to use one - or more preconfigured keys (or key hashes) other than the root key, - or may not provide preconfigured knowledge of the root key, or may - prevent the resolver from using particular keys for arbitrary reasons - even if those keys are properly signed with verifiable signatures. - DNSSEC provides mechanisms by which a security-aware resolver can - determine whether an RRset's signature is "valid" within the meaning - of DNSSEC. In the final analysis however, authenticating both DNS - keys and data is a matter of local policy, which may extend or even - override the protocol extensions defined in this document set. - -3.2 Authenticating Name and Type Non-Existence - - The security mechanism described in Section 3.1 only provides a way - to sign existing RRsets in a zone. The problem of providing negative - responses with the same level of authentication and integrity - requires the use of another new resource record type, the NSEC - record. The NSEC record allows a security-aware resolver to - authenticate a negative reply for either name or type non-existence - via the same mechanisms used to authenticate other DNS replies. Use - - - -Arends, et al. Expires August 16, 2004 [Page 8] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - of NSEC records requires a canonical representation and ordering for - domain names in zones. Chains of NSEC records explicitly describe - the gaps, or "empty space", between domain names in a zone, as well - as listing the types of RRsets present at existing names. Each NSEC - record is signed and authenticated using the mechanisms described in - Section 3.1. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 9] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -4. Services Not Provided by DNS Security - - DNS was originally designed with the assumptions that the DNS will - return the same answer to any given query regardless of who may have - issued the query, and that all data in the DNS is thus visible. - Accordingly, DNSSEC is not designed to provide confidentiality, - access control lists, or other means of differentiating between - inquirers. - - DNSSEC provides no protection against denial of service attacks. - Security-aware resolvers and security-aware name servers are - vulnerable to an additional class of denial of service attacks based - on cryptographic operations. Please see Section 11 for details. - - The DNS security extensions provide data and origin authentication - for DNS data. The mechanisms outlined above are not designed to - protect operations such as zone transfers and dynamic update - [RFC3007]. Message authentication schemes described in [RFC2845] and - [RFC2931] address security operations that pertain to these - transactions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 10] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -5. Resolver Considerations - - A security-aware resolver needs to be able to perform cryptographic - functions necessary to verify digital signatures using at least the - mandatory-to-implement algorithm(s). Security-aware resolvers must - also be capable of forming an authentication chain from a newly - learned zone back to an authentication key, as described above. This - process might require additional queries to intermediate DNS zones to - obtain necessary DNSKEY, DS and RRSIG records. A security-aware - resolver should be configured with at least one authentication key or - a key's DS RR hash as the starting point from which it will attempt - to establish authentication chains. - - If a security-aware resolver is separated from the relevant - authoritative name servers by a recursive name server or by any sort - of device which acts as a proxy for DNS, and if the recursive name - server or proxy is not security-aware, the security-aware resolver - may not be capable of operating in a secure mode. For example, if a - security-aware resolver's packets are routed through a network - address translation device that includes a DNS proxy which is not - security-aware, the security-aware resolver may find it difficult or - impossible to obtain or validate signed DNS data. - - If a security-aware resolver must rely on an unsigned zone or a name - server that is not security aware, the resolver may not be able to - validate DNS responses, and will need a local policy on whether to - accept unverified responses. - - A security-aware resolver should take a signature's validation period - into consideration when determining the TTL of data in its cache, to - avoid caching signed data beyond the validity period of the - signature, but should also allow for the possibility that the - security-aware resolver's own clock is wrong. Thus, a security-aware - resolver which is part of a security-aware recursive name server will - need to pay careful attention to the DNSSEC "checking disabled" (CD) - bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid - blocking valid signatures from getting through to other - security-aware resolvers which are clients of this recursive name - server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure - recursive server handles queries with the CD bit set. - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 11] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -6. Stub Resolver Considerations - - Although not strictly required to do so by the protocol, most DNS - queries originate from stub resolvers. Stub resolvers, by - definition, are minimal DNS resolvers which use recursive query mode - to offload most of the work of DNS resolution to a recursive name - server. Given the widespread use of stub resolvers, the DNSSEC - architecture has to take stub resolvers into account, but the - security features needed in a stub resolver differ in some respects - from those needed in a full security-aware resolver. - - Even an unaugmented stub resolver may get some benefit from DNSSEC if - the recursive name servers it uses are security-aware, but for the - stub resolver to place any real reliance on DNSSEC services, the stub - resolver must trust both the recursive name servers in question and - the communication channels between itself and those name servers. - The first of these issues is a local policy issue: in essence, a - security-oblivious stub resolver has no real choice but to place - itself at the mercy of the recursive name servers that it uses, since - it does not perform DNSSEC validity checks on its own. The second - issue requires some kind of channel security mechanism; proper use of - DNS transaction authentication mechanisms such as SIG(0) or TSIG - would suffice, as would appropriate use of IPsec, and particular - implementations may have other choices available, such as operating - system specific interprocess communication mechanisms. - Confidentiality is not needed for this channel, but data integrity - and message authentication are. - - A security-aware stub resolver which does trust both its recursive - name servers and its communication channel to them may choose to - examine the setting of the AD bit in the message header of the - response messages it receives. The stub resolver can use this flag - bit as a hint to find out whether the recursive name server was able - to validate signatures for all of the data in the Answer and - Authority sections of the response. - - There is one more step which a security-aware stub resolver can take - if, for whatever reason, it is not able to establish a useful trust - relationship with the recursive name servers which it uses: it can - perform its own signature validation, by setting the Checking - Disabled (CD) bit in its query messages. A validating stub resolver - is thus able to treat the DNSSEC signatures as a trust relationship - between the zone administrator and the stub resolver itself. - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 12] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -7. Zone Considerations - - There are several differences between signed and unsigned zones. A - signed zone will contain additional security-related records (RRSIG, - DNSKEY, DS and NSEC records). RRSIG and NSEC records may be - generated by a signing process prior to serving the zone. The RRSIG - records that accompany zone data have defined inception and - expiration times, which establish a validity period for the - signatures and the zone data the signatures cover. - -7.1 TTL values vs. RRSIG validity period - - It is important to note the distinction between a RRset's TTL value - and the signature validity period specified by the RRSIG RR covering - that RRset. DNSSEC does not change the definition or function of the - TTL value, which is intended to maintain database coherency in - caches. A caching resolver purges RRsets from its cache no later than - the end of the time period specified by the TTL fields of those - RRsets, regardless of whether or not the resolver is security-aware. - - The inception and expiration fields in the RRSIG RR - [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time - period during which the signature can be used to validate the RRset - that it covers. The signatures associated with signed zone data are - only valid for the time period specified by these fields in the RRSIG - RRs in question. TTL values cannot extend the validity period of - signed RRsets in a resolver's cache, but the resolver may use the - time remaining before expiration of the signature validity period of - a signed RRset as an upper bound for the TTL of the signed RRset and - its associated RRSIG RR in the resolver's cache. - -7.2 New Temporal Dependency Issues for Zones - - Information in a signed zone has a temporal dependency which did not - exist in the original DNS protocol. A signed zone requires regular - maintenance to ensure that each RRset in the zone has a current valid - RRSIG RR. The signature validity period of an RRSIG RR is an - interval during which the signature for one particular signed RRset - can be considered valid, and the signatures of different RRsets in a - zone may expire at different times. Re-signing one or more RRsets in - a zone will change one or more RRSIG RRs, which in turn will require - incrementing the zone's SOA serial number to indicate that a zone - change has occurred and re-signing the SOA RRset itself. Thus, - re-signing any RRset in a zone may also trigger DNS NOTIFY messages - and zone transfers operations. - - - - - - -Arends, et al. Expires August 16, 2004 [Page 13] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -8. Name Server Considerations - - A security-aware name server should include the appropriate DNSSEC - records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from - resolvers which have signaled their willingness to receive such - records via use of the DO bit in the EDNS header, subject to message - size limitations. Since inclusion of these DNSSEC RRs could easily - cause UDP message truncation and fallback to TCP, a security-aware - name server must also support the EDNS "sender's UDP payload" - mechanism. - - If possible, the private half of each DNSSEC key pair should be kept - offline, but this will not be possible for a zone for which DNS - dynamic update has been enabled. In the dynamic update case, the - primary master server for the zone will have to re-sign the zone when - updated, so the private half of the zone signing key will have to be - kept online. This is an example of a situation where the ability to - separate the zone's DNSKEY RRset into zone signing key(s) and key - signing key(s) may be useful, since the key signing key(s) in such a - case can still be kept offline. - - DNSSEC, by itself, is not enough to protect the integrity of an - entire zone during zone transfer operations, since even a signed zone - contains some unsigned, nonauthoritative data if the zone has any - children, so zone maintenance operations will require some additional - mechanisms (most likely some form of channel security, such as TSIG, - SIG(0), or IPsec). - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 14] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -9. DNS Security Document Family - - The DNSSEC document set can be partitioned into several main groups, - under the larger umbrella of the DNS base protocol documents. - - The "DNSSEC protocol document set" refers to the three documents - which form the core of the DNS security extensions: - - 1. DNS Security Introduction and Requirements (this document) - - 2. Resource Records for DNS Security Extensions - [I-D.ietf-dnsext-dnssec-records] - - 3. Protocol Modifications for the DNS Security Extensions - [I-D.ietf-dnsext-dnssec-protocol] - - The "Digital Signature Algorithm Specification" document set refers - to the group of documents that describe how specific digital - signature algorithms should be implemented to fit the DNSSEC resource - record format. Each of these documents deals with a specific digital - signature algorithm. - - The "Transaction Authentication Protocol" document set refers to the - group of documents that deal with DNS message authentication, - including secret key establishment and verification. While not - strictly part of the DNSSEC specification as defined in this set of - documents, this group is noted to show its relationship to DNSSEC. - - The final document set, "New Security Uses", refers to documents that - seek to use proposed DNS Security extensions for other security - related purposes. DNSSEC does not provide any direct security for - these new uses, but may be used to support them. Documents that fall - in this category include the use of DNS in the storage and - distribution of certificates [RFC2538]. - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 15] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -10. IANA Considerations - - This overview document introduces no new IANA considerations. Please - see [I-D.ietf-dnsext-dnssec-records] for a complete review of the - IANA considerations introduced by DNSSEC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 16] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -11. Security Considerations - - This document introduces the DNS security extensions and describes - the document set that contains the new security records and DNS - protocol modifications. This document discusses the capabilities and - limitations of these extensions. The extensions provide data origin - authentication and data integrity using digital signatures over - resource record sets. - - In order for a security-aware resolver to validate a DNS response, - all zones along the path from the trusted starting point to the zone - containing the response zones must be signed, and all name servers - and resolvers involved in the resolution process must be - security-aware, as defined in this document set. A security-aware - resolver cannot verify responses originating from an unsigned zone, - from a zone not served by a security-aware name server, or for any - DNS data which the resolver is only able to obtain through a - recursive name server which is not security-aware. If there is a - break in the authentication chain such that a security-aware resolver - cannot obtain and validate the authentication keys it needs, then the - security-aware resolver cannot validate the affected DNS data. - - This document briefly discusses other methods of adding security to a - DNS query, such as using a channel secured by IPsec or using a DNS - transaction authentication mechanism, but transaction security is not - part of DNSSEC per se. - - A non-validating security-aware stub resolver, by definition, does - not perform DNSSEC signature validation on its own, and thus is - vulnerable both to attacks on (and by) the security-aware recursive - name servers which perform these checks on its behalf and also to - attacks on its communication with those security-aware recursive name - servers. Non-validating security-aware stub resolvers should use some - form of channel security to defend against the latter threat. The - only known defense against the former threat would be for the - security-aware stub resolver to perform its own signature validation, - at which point, again by definition, it would no longer be a - non-validating security-aware stub resolver. - - DNSSEC does not protect against denial of service attacks. DNSSEC - makes DNS vulnerable to a new class of denial of service attacks - based on cryptographic operations against security-aware resolvers - and security-aware name servers, since an attacker can attempt to use - DNSSEC mechanisms to consume a victim's resources. This class of - attacks takes at least two forms. An attacker may be able to consume - resources in a security-aware resolver's signature validation code by - tampering with RRSIG RRs in response messages or by constructing - needlessly complex signature chains. An attacker may also be able to - - - -Arends, et al. Expires August 16, 2004 [Page 17] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - consume resources in a security-aware name server which supports DNS - dynamic update, by sending a stream of update messages that force the - security-aware name server to re-sign some RRsets in the zone more - frequently than would otherwise be necessary. - - DNSSEC introduces the ability for a hostile party to enumerate all - the names in a zone by following the NSEC chain. NSEC RRs assert - which names do not exist in a zone by linking from existing name to - existing name along a canonical ordering of all the names within a - zone. Thus, an attacker can query these NSEC RRs in sequence to - obtain all the names in a zone. While not an attack on the DNS - itself, this could allow an attacker to map network hosts or other - resources by enumerating the contents of a zone. There are non-DNS - protocol means of detecting and limiting this attack beyond the scope - of this document set. - - DNSSEC introduces significant additional complexity to the DNS, and - thus introduces many new opportunities for implementation bugs and - misconfigured zones. In particular, enabling DNSSEC signature - validation in a resolver may cause entire legitimate zones to become - effectively unreachable due to DNSSEC configuration errors or bugs. - - DNSSEC does not provide confidentiality, due to a deliberate design - choice. - - DNSSEC does not protect against tampering with unsigned zone data. - Non-authoritative data at zone cuts (glue and NS RRs in the parent - zone) are not signed. This does not pose a problem when validating - the authentication chain, but does mean that the non-authoritative - data itself is vulnerable to tampering during zone transfer - operations. Thus, while DNSSEC can provide data origin - authentication and data integrity for RRsets, it cannot do so for - zones, and other mechanisms must be used to protect zone transfer - operations. - - Please see [I-D.ietf-dnsext-dnssec-records] and - [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations. - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 18] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -12. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group. While explicitly listing everyone - who has contributed during the decade during which DNSSEC has been - under development would be an impossible task, the editors would - particularly like to thank the following people for their - contributions to and comments on this document set: Mark Andrews, - Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, - Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael - Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip - Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf - Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted - Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson, - Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik - Rozendaal, Jakob Schlyter, Mike StJohns, Sam Weiler, and Brian - Wellington. - - No doubt the above is an incomplete list. We apologize to anyone we - left out. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 19] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-07 (work in progress), - February 2004. - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in - progress), February 2004. - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 20] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -Informative References - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in - the Domain Name System (DNS)", RFC 2538, March 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) - Signing Authority", RFC 3008, November 2000. - - [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [I-D.ietf-dnsext-dns-threats] - Atkins, D. and R. Austein, "Threat Analysis Of The Domain - Name System", draft-ietf-dnsext-dns-threats-05 (work in - progress), November 2003. - - [I-D.ietf-dnsext-dnssec-2535typecode-change] - Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06 - - - -Arends, et al. Expires August 16, 2004 [Page 21] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - (work in progress), December 2003. - - [I-D.ietf-dnsext-keyrr-key-signing-flag] - Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", - draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in - progress), December 2003. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - - - - -Arends, et al. Expires August 16, 2004 [Page 22] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 23] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires August 16, 2004 [Page 24] - -Internet-Draft DNSSEC Introduction and Requirements February 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 25] - - +
+
+DNS Extensions R. Arends
+Internet-Draft Telematica Instituut
+Expires: November 15, 2004 R. Austein
+ ISC
+ M. Larson
+ VeriSign
+ D. Massey
+ USC/ISI
+ S. Rose
+ NIST
+ May 17, 2004
+
+
+ DNS Security Introduction and Requirements
+ draft-ietf-dnsext-dnssec-intro-10
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on November 15, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ The Domain Name System Security Extensions (DNSSEC) add data origin
+ authentication and data integrity to the Domain Name System. This
+ document introduces these extensions, and describes their
+ capabilities and limitations. This document also discusses the
+ services that the DNS security extensions do and do not provide.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 1]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+ Last, this document describes the interrelationships between the
+ group of documents that collectively describe DNSSEC.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4
+ 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8
+ 3.1 Data Origin Authentication and Data Integrity . . . . . . 8
+ 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9
+ 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11
+ 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12
+ 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14
+ 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15
+ 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16
+ 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16
+ 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16
+ 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17
+ 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18
+ 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
+ 12. Security Considerations . . . . . . . . . . . . . . . . . . 20
+ 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
+ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
+ 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
+ Intellectual Property and Copyright Statements . . . . . . . . 26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 2]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+1. Introduction
+
+ This document introduces the Domain Name System Security Extensions
+ (DNSSEC). This document and its two companion documents
+ ([I-D.ietf-dnsext-dnssec-records] and
+ [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
+ security extensions defined in RFC 2535 [RFC2535] and its
+ predecessors. These security extensions consist of a set of new
+ resource record types and modifications to the existing DNS protocol
+ [RFC1035]. The new records and protocol modifications are not fully
+ described in this document, but are described in a family of
+ documents outlined in Section 10. Section 3 and Section 4 describe
+ the capabilities and limitations of the security extensions in
+ greater detail. Section 5 discusses the scope of the document set.
+ Section 6, Section 7, Section 8, and Section 9 discuss the effect
+ that these security extensions will have on resolvers, stub
+ resolvers, zones and name servers.
+
+ This document and its two companions update and obsolete RFCs 2535
+ [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655
+ [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress
+ [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but
+ does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
+ [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts
+ of 3226 [RFC3226] (dealing with DNSSEC).
+
+ The DNS security extensions provide origin authentication and
+ integrity protection for DNS data, as well as a means of public key
+ distribution. These extensions do not provide confidentiality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 3]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+2. Definitions of Important DNSSEC Terms
+
+ This section defines a number of terms used in this document set.
+ Since this is intended to be useful as a reference while reading the
+ rest of the document set, first-time readers may wish to skim this
+ section quickly, read the rest of this document, then come back to
+ this section.
+
+ Authentication Chain: An alternating sequence of DNSKEY RRsets and DS
+ RRsets forms a chain of signed data, with each link in the chain
+ vouching for the next. A DNSKEY RR is used to verify the
+ signature covering a DS RR and allows the DS RR to be
+ authenticated. The DS RR contains a hash of another DNSKEY RR and
+ this new DNSKEY RR is authenticated by matching the hash in the DS
+ RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset
+ and, in turn, some DNSKEY RR in this set may be used to
+ authenticate another DS RR and so forth until the chain finally
+ ends with a DNSKEY RR whose corresponding private key signs the
+ desired DNS data. For example, the root DNSKEY RRset can be used
+ to authenticate the DS RRset for "example." The "example." DS
+ RRset contains a hash that matches some "example." DNSKEY, and
+ this DNSKEY's corresponding private key signs the "example."
+ DNSKEY RRset. Private key counterparts of the "example." DNSKEY
+ RRset sign data records such as "www.example." as well as DS RRs
+ for delegations such as "subzone.example."
+
+ Authentication Key: A public key that a security-aware resolver has
+ verified and can therefore use to authenticate data. A
+ security-aware resolver can obtain authentication keys in three
+ ways. First, the resolver is generally configured to know about
+ at least one public key; this configured data is usually either
+ the public key itself or a hash of the public key as found in the
+ DS RR (see "trust anchor"). Second, the resolver may use an
+ authenticated public key to verify a DS RR and its associated
+ DNSKEY RR. Third, the resolver may be able to determine that a
+ new public key has been signed by the private key corresponding to
+ another public key which the resolver has verified. Note that the
+ resolver must always be guided by local policy when deciding
+ whether to authenticate a new public key, even if the local policy
+ is simply to authenticate any new public key for which the
+ resolver is able verify the signature.
+
+ Delegation Point: Term used to describe the name at the parental side
+ of a zone cut. That is, the delegation point for "foo.example"
+ would be the foo.example node in the "example" zone (as opposed to
+ the zone apex of the "foo.example" zone).
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 4]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+ Island of Security: Term used to describe a signed, delegated zone
+ that does not have an authentication chain from its delegating
+ parent. That is, there is no DS RR containing a hash of a DNSKEY
+ RR for the island in its delegating parent zone (see
+ [I-D.ietf-dnsext-dnssec-records]). An island of security is served
+ by security-aware name servers and may provide authentication
+ chains to any delegated child zones. Responses from an island of
+ security or its descendents can only be authenticated if its
+ authentication keys can be authenticated by some trusted means out
+ of band from the DNS protocol.
+
+ Key Signing Key: An authentication key that corresponds to a private
+ key used to sign one or more other authentication keys for a given
+ zone. Typically, the private key corresponding to a key signing
+ key will sign a zone signing key, which in turn has a
+ corresponding private key which will sign other zone data. Local
+ policy may require the zone signing key to be changed frequently,
+ while the key signing key may have a longer validity period in
+ order to provide a more stable secure entry point into the zone.
+ Designating an authentication key as a key signing key is purely
+ an operational issue: DNSSEC validation does not distinguish
+ between key signing keys and other DNSSEC authentication keys, and
+ it is possible to use a single key as both a key signing key and a
+ zone signing key. Key signing keys are discussed in more detail
+ in [RFC3757]. Also see: zone signing key.
+
+ Non-Validating Security-Aware Stub Resolver: A security-aware stub
+ resolver which trusts one or more security-aware recursive name
+ servers to perform most of the tasks discussed in this document
+ set on its behalf. In particular, a non-validating security-aware
+ stub resolver is an entity which sends DNS queries, receives DNS
+ responses, and is capable of establishing an appropriately secured
+ channel to a security-aware recursive name server which will
+ provide these services on behalf of the security-aware stub
+ resolver. See also: security-aware stub resolver, validating
+ security-aware stub resolver.
+
+ Non-Validating Stub Resolver: A less tedious term for a
+ non-validating security-aware stub resolver.
+
+ Security-Aware Name Server: An entity acting in the role of a name
+ server (defined in section 2.4 of [RFC1034]) that understands the
+ DNS security extensions defined in this document set. In
+ particular, a security-aware name server is an entity which
+ receives DNS queries, sends DNS responses, supports the EDNS0
+ [RFC2671] message size extension and the DO bit [RFC3225], and
+ supports the RR types and message header bits defined in this
+ document set.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 5]
+
+
+ Security-Aware Recursive Name Server: An entity which acts in both
+ the security-aware name server and security-aware resolver roles.
+ A more cumbersome equivalent phrase would be "a security-aware
+ name server which offers recursive service".
+
+ Security-Aware Resolver: An entity acting in the role of a resolver
+ (defined in section 2.4 of [RFC1034]) which understands the DNS
+ security extensions defined in this document set. In particular,
+ a security-aware resolver is an entity which sends DNS queries,
+ receives DNS responses, supports the EDNS0 [RFC2671] message size
+ extension and the DO bit [RFC3225], and is capable of using the RR
+ types and message header bits defined in this document set to
+ provide DNSSEC services.
+
+ Security-Aware Stub Resolver: An entity acting in the role of a stub
+ resolver (defined in section 5.3.1 of [RFC1034]) which has enough
+ of an understanding the DNS security extensions defined in this
+ document set to provide additional services not available from a
+ security-oblivious stub resolver. Security-aware stub resolvers
+ may be either "validating" or "non-validating" depending on
+ whether the stub resolver attempts to verify DNSSEC signatures on
+ its own or trusts a friendly security-aware name server to do so.
+ See also: validating stub resolver, non-validating stub resolver.
+
+ Security-Oblivious <anything>: An <anything> that is not
+ "security-aware".
+
+ Signed Zone: A zone whose RRsets are signed and which contains
+ properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
+ records.
+
+ Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A
+ validating security-aware resolver uses this public key or hash as
+ a starting point for building the authentication chain to a signed
+ DNS response. In general, a validating resolver will need to
+ obtain the initial values of its trust anchors via some secure or
+ trusted means outside the DNS protocol. Presence of a trust
+ anchor also implies that the resolver should expect the zone to
+ which the trust anchor points to be signed
+
+ Unsigned Zone: A zone that is not signed.
+
+ Validating Security-Aware Stub Resolver: A security-aware resolver
+ that sends queries in recursive mode but which performs signature
+ validation on its own rather than just blindly trusting an
+ upstream security-aware recursive name server. See also:
+ security-aware stub resolver, non-validating security-aware stub
+ resolver.
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 6]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+ Validating Stub Resolver: A less tedious term for a validating
+ security-aware stub resolver.
+
+ Zone Signing Key: An authentication key that corresponds to a private
+ key used to sign a zone. Typically a zone signing key will be
+ part of the same DNSKEY RRset as the key signing key whose
+ corresponding private key signs this DNSKEY RRset, but the zone
+ signing key is used for a slightly different purpose, and may
+ differ from the key signing key in other ways, such as validity
+ lifetime. Designating an authentication key as a zone signing key
+ is purely an operational issue: DNSSEC validation does not
+ distinguish between zone signing keys and other DNSSEC
+ authentication keys, and it is possible to use a single key as
+ both a key signing key and a zone signing key. See also: key
+ signing key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 7]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+3. Services Provided by DNS Security
+
+ The Domain Name System (DNS) security extensions provide origin
+ authentication and integrity assurance services for DNS data,
+ including mechanisms for authenticated denial of existence of DNS
+ data. These mechanisms are described below.
+
+ These mechanisms require changes to the DNS protocol. DNSSEC adds
+ four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two
+ new message header bits (CD and AD). In order to support the larger
+ DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
+ requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support
+ for the DO bit [RFC3225], so that a security-aware resolver can
+ indicate in its queries that it wishes to receive DNSSEC RRs in
+ response messages.
+
+ These services protect against most of the threats to the Domain Name
+ System described in [I-D.ietf-dnsext-dns-threats].
+
+3.1 Data Origin Authentication and Data Integrity
+
+ DNSSEC provides authentication by associating cryptographically
+ generated digital signatures with DNS RRsets. These digital
+ signatures are stored in a new resource record, the RRSIG record.
+ Typically, there will be a single private key that signs a zone's
+ data, but multiple keys are possible: for example, there may be keys
+ for each of several different digital signature algorithms. If a
+ security-aware resolver reliably learns a zone's public key, it can
+ authenticate that zone's signed data. An important DNSSEC concept is
+ that the key that signs a zone's data is associated with the zone
+ itself and not with the zone's authoritative name servers (public
+ keys for DNS transaction authentication mechanisms may also appear in
+ zones, as described in [RFC2931], but DNSSEC itself is concerned with
+ object security of DNS data, not channel security of DNS
+ transactions).
+
+ A security-aware resolver can learn a zone's public key either by
+ having a trust anchor configured into the resolver or by normal DNS
+ resolution. To allow the latter, public keys are stored in a new
+ type of resource record, the DNSKEY RR. Note that the private keys
+ used to sign zone data must be kept secure, and should be stored
+ offline when practical to do so. To discover a public key reliably
+ via DNS resolution, the target key itself needs to be signed by
+ either a configured authentication key or another key that has been
+ authenticated previously. Security-aware resolvers authenticate zone
+ information by forming an authentication chain from a newly learned
+ public key back to a previously known authentication public key,
+ which in turn either has been configured into the resolver or must
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 8]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+ have been learned and verified previously. Therefore, the resolver
+ must be configured with at least one trust anchor. If the configured
+ key is a zone signing key, then it will authenticate the associated
+ zone; if the configured key is a key signing key, it will
+ authenticate a zone signing key. If the resolver has been configured
+ with the hash of a key rather than the key itself, the resolver may
+ need to obtain the key via a DNS query. To help security-aware
+ resolvers establish this authentication chain, security-aware name
+ servers attempt to send the signature(s) needed to authenticate a
+ zone's public key(s) in the DNS reply message along with the public
+ key itself, provided there is space available in the message.
+
+ The Delegation Signer (DS) RR type simplifies some of the
+ administrative tasks involved in signing delegations across
+ organizational boundaries. The DS RRset resides at a delegation
+ point in a parent zone and indicates the public key(s) corresponding
+ to the private key(s) used to self-sign the DNSKEY RRset at the
+ delegated child zone's apex. The administrator of the child zone, in
+ turn, uses the private key(s) corresponding to one or more of the
+ public keys in this DNSKEY RRset to sign the child zone's data. The
+ typical authentication chain is therefore
+ DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
+ DS->DNSKEY subchains. DNSSEC permits more complex authentication
+ chains, such as additional layers of DNSKEY RRs signing other DNSKEY
+ RRs within a zone.
+
+ A security-aware resolver normally constructs this authentication
+ chain from the root of the DNS hierarchy down to the leaf zones based
+ on configured knowledge of the public key for the root. Local
+ policy, however, may also allow a security-aware resolver to use one
+ or more configured public keys (or hashes of public keys) other than
+ the root public key, or may not provide configured knowledge of the
+ root public key, or may prevent the resolver from using particular
+ public keys for arbitrary reasons even if those public keys are
+ properly signed with verifiable signatures. DNSSEC provides
+ mechanisms by which a security-aware resolver can determine whether
+ an RRset's signature is "valid" within the meaning of DNSSEC. In the
+ final analysis however, authenticating both DNS keys and data is a
+ matter of local policy, which may extend or even override the
+ protocol extensions defined in this document set. See for further
+ discussion.
+
+3.2 Authenticating Name and Type Non-Existence
+
+ The security mechanism described in Section 3.1 only provides a way
+ to sign existing RRsets in a zone. The problem of providing negative
+ responses with the same level of authentication and integrity
+ requires the use of another new resource record type, the NSEC
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 9]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+ record. The NSEC record allows a security-aware resolver to
+ authenticate a negative reply for either name or type non-existence
+ via the same mechanisms used to authenticate other DNS replies. Use
+ of NSEC records requires a canonical representation and ordering for
+ domain names in zones. Chains of NSEC records explicitly describe
+ the gaps, or "empty space", between domain names in a zone, as well
+ as listing the types of RRsets present at existing names. Each NSEC
+ record is signed and authenticated using the mechanisms described in
+ Section 3.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 10]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+4. Services Not Provided by DNS Security
+
+ DNS was originally designed with the assumptions that the DNS will
+ return the same answer to any given query regardless of who may have
+ issued the query, and that all data in the DNS is thus visible.
+ Accordingly, DNSSEC is not designed to provide confidentiality,
+ access control lists, or other means of differentiating between
+ inquirers.
+
+ DNSSEC provides no protection against denial of service attacks.
+ Security-aware resolvers and security-aware name servers are
+ vulnerable to an additional class of denial of service attacks based
+ on cryptographic operations. Please see Section 12 for details.
+
+ The DNS security extensions provide data and origin authentication
+ for DNS data. The mechanisms outlined above are not designed to
+ protect operations such as zone transfers and dynamic update
+ [RFC3007]. Message authentication schemes described in [RFC2845] and
+ [RFC2931] address security operations that pertain to these
+ transactions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 11]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+5. Scope of the DNSSEC Document Set and Last Hop Issues
+
+ The specification in this document set defines the behavior for zone
+ signers and security-aware name servers and resolvers in such a way
+ that the validating entities can unambiguously determine the state of
+ the data.
+
+ A validating resolver can determine these 4 states:
+
+ Secure: The validating resolver has a trust anchor, a chain of trust
+ and is able to verify all the signatures in the response.
+
+ Insecure: The validating resolver has a trust anchor, a chain of
+ trust, and, at some delegation point, signed proof of the
+ non-existence of a DS record. That indicates that subsequent
+ branches in the tree are provably insecure. A validating resolver
+ may have local policy to mark parts of the domain space as
+ insecure.
+
+ Bogus: The validating resolver has a trust anchor and there is a
+ secure delegation which is indicating that subsidiary data will be
+ signed, but the response fails to validate due to one or more
+ reasons: missing signatures, expired signatures, signatures with
+ unsupported algorithms, data missing which the relevant NSEC RR
+ says should be present, and so forth.
+
+ Indeterminate: There is no trust anchor which would indicate that a
+ specific portion of the tree is secure. This is the default
+ operation mode.
+
+ This specification only defines how security aware name servers can
+ signal non-validating stub resolvers that data was found to be bogus
+ (using RCODE=2, "Server Failure" -- see
+ [I-D.ietf-dnsext-dnssec-protocol]).
+
+ There is a mechanism for security aware name servers to signal
+ security-aware stub resolvers that data was found to be secure (using
+ the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]).
+
+ This specification does not define a format for communicating why
+ responses were found to be bogus or marked as insecure. The current
+ signaling mechanism does not distinguish between indeterminate and
+ insecure.
+
+ A method for signaling advanced error codes and policy between a
+ security aware stub resolver and security aware recursive nameservers
+ is a topic for future work, as is the interface between a security
+ aware resolver and the applications that use it. Note, however, that
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 12]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+ the lack of the specification of such communication does not prohibit
+ deployment of signed zones or the deployment of security aware
+ recursive name servers that prohibit propagation of bogus data to the
+ applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 13]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+6. Resolver Considerations
+
+ A security-aware resolver needs to be able to perform cryptographic
+ functions necessary to verify digital signatures using at least the
+ mandatory-to-implement algorithm(s). Security-aware resolvers must
+ also be capable of forming an authentication chain from a newly
+ learned zone back to an authentication key, as described above. This
+ process might require additional queries to intermediate DNS zones to
+ obtain necessary DNSKEY, DS and RRSIG records. A security-aware
+ resolver should be configured with at least one trust anchor as the
+ starting point from which it will attempt to establish authentication
+ chains.
+
+ If a security-aware resolver is separated from the relevant
+ authoritative name servers by a recursive name server or by any sort
+ of device which acts as a proxy for DNS, and if the recursive name
+ server or proxy is not security-aware, the security-aware resolver
+ may not be capable of operating in a secure mode. For example, if a
+ security-aware resolver's packets are routed through a network
+ address translation device that includes a DNS proxy which is not
+ security-aware, the security-aware resolver may find it difficult or
+ impossible to obtain or validate signed DNS data.
+
+ If a security-aware resolver must rely on an unsigned zone or a name
+ server that is not security aware, the resolver may not be able to
+ validate DNS responses, and will need a local policy on whether to
+ accept unverified responses.
+
+ A security-aware resolver should take a signature's validation period
+ into consideration when determining the TTL of data in its cache, to
+ avoid caching signed data beyond the validity period of the
+ signature, but should also allow for the possibility that the
+ security-aware resolver's own clock is wrong. Thus, a security-aware
+ resolver which is part of a security-aware recursive name server will
+ need to pay careful attention to the DNSSEC "checking disabled" (CD)
+ bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid
+ blocking valid signatures from getting through to other
+ security-aware resolvers which are clients of this recursive name
+ server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure
+ recursive server handles queries with the CD bit set.
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 14]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+7. Stub Resolver Considerations
+
+ Although not strictly required to do so by the protocol, most DNS
+ queries originate from stub resolvers. Stub resolvers, by
+ definition, are minimal DNS resolvers which use recursive query mode
+ to offload most of the work of DNS resolution to a recursive name
+ server. Given the widespread use of stub resolvers, the DNSSEC
+ architecture has to take stub resolvers into account, but the
+ security features needed in a stub resolver differ in some respects
+ from those needed in a full security-aware resolver.
+
+ Even a security-oblivious stub resolver may get some benefit from
+ DNSSEC if the recursive name servers it uses are security-aware, but
+ for the stub resolver to place any real reliance on DNSSEC services,
+ the stub resolver must trust both the recursive name servers in
+ question and the communication channels between itself and those name
+ servers. The first of these issues is a local policy issue: in
+ essence, a security-oblivious stub resolver has no real choice but to
+ place itself at the mercy of the recursive name servers that it uses,
+ since it does not perform DNSSEC validity checks on its own. The
+ second issue requires some kind of channel security mechanism; proper
+ use of DNS transaction authentication mechanisms such as SIG(0) or
+ TSIG would suffice, as would appropriate use of IPsec, and particular
+ implementations may have other choices available, such as operating
+ system specific interprocess communication mechanisms.
+ Confidentiality is not needed for this channel, but data integrity
+ and message authentication are.
+
+ A security-aware stub resolver that does trust both its recursive
+ name servers and its communication channel to them may choose to
+ examine the setting of the AD bit in the message header of the
+ response messages it receives. The stub resolver can use this flag
+ bit as a hint to find out whether the recursive name server was able
+ to validate signatures for all of the data in the Answer and
+ Authority sections of the response.
+
+ There is one more step that a security-aware stub resolver can take
+ if, for whatever reason, it is not able to establish a useful trust
+ relationship with the recursive name servers which it uses: it can
+ perform its own signature validation, by setting the Checking
+ Disabled (CD) bit in its query messages. A validating stub resolver
+ is thus able to treat the DNSSEC signatures as a trust relationship
+ between the zone administrator and the stub resolver itself.
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 15]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+8. Zone Considerations
+
+ There are several differences between signed and unsigned zones. A
+ signed zone will contain additional security-related records (RRSIG,
+ DNSKEY, DS and NSEC records). RRSIG and NSEC records may be
+ generated by a signing process prior to serving the zone. The RRSIG
+ records that accompany zone data have defined inception and
+ expiration times, which establish a validity period for the
+ signatures and the zone data the signatures cover.
+
+8.1 TTL values vs. RRSIG validity period
+
+ It is important to note the distinction between a RRset's TTL value
+ and the signature validity period specified by the RRSIG RR covering
+ that RRset. DNSSEC does not change the definition or function of the
+ TTL value, which is intended to maintain database coherency in
+ caches. A caching resolver purges RRsets from its cache no later than
+ the end of the time period specified by the TTL fields of those
+ RRsets, regardless of whether or not the resolver is security-aware.
+
+ The inception and expiration fields in the RRSIG RR
+ [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time
+ period during which the signature can be used to validate the covered
+ RRset. The signatures associated with signed zone data are only
+ valid for the time period specified by these fields in the RRSIG RRs
+ in question. TTL values cannot extend the validity period of signed
+ RRsets in a resolver's cache, but the resolver may use the time
+ remaining before expiration of the signature validity period of a
+ signed RRset as an upper bound for the TTL of the signed RRset and
+ its associated RRSIG RR in the resolver's cache.
+
+8.2 New Temporal Dependency Issues for Zones
+
+ Information in a signed zone has a temporal dependency which did not
+ exist in the original DNS protocol. A signed zone requires regular
+ maintenance to ensure that each RRset in the zone has a current valid
+ RRSIG RR. The signature validity period of an RRSIG RR is an
+ interval during which the signature for one particular signed RRset
+ can be considered valid, and the signatures of different RRsets in a
+ zone may expire at different times. Re-signing one or more RRsets in
+ a zone will change one or more RRSIG RRs, which in turn will require
+ incrementing the zone's SOA serial number to indicate that a zone
+ change has occurred and re-signing the SOA RRset itself. Thus,
+ re-signing any RRset in a zone may also trigger DNS NOTIFY messages
+ and zone transfers operations.
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 16]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+9. Name Server Considerations
+
+ A security-aware name server should include the appropriate DNSSEC
+ records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from
+ resolvers which have signaled their willingness to receive such
+ records via use of the DO bit in the EDNS header, subject to message
+ size limitations. Since inclusion of these DNSSEC RRs could easily
+ cause UDP message truncation and fallback to TCP, a security-aware
+ name server must also support the EDNS "sender's UDP payload"
+ mechanism.
+
+ If possible, the private half of each DNSSEC key pair should be kept
+ offline, but this will not be possible for a zone for which DNS
+ dynamic update has been enabled. In the dynamic update case, the
+ primary master server for the zone will have to re-sign the zone when
+ updated, so the private key corresponding to the zone signing key
+ will have to be kept online. This is an example of a situation where
+ the ability to separate the zone's DNSKEY RRset into zone signing
+ key(s) and key signing key(s) may be useful, since the key signing
+ key(s) in such a case can still be kept offline and may have a longer
+ useful lifetime than the zone signing key(s).
+
+ DNSSEC, by itself, is not enough to protect the integrity of an
+ entire zone during zone transfer operations, since even a signed zone
+ contains some unsigned, nonauthoritative data if the zone has any
+ children. Therefore, zone maintenance operations will require some
+ additional mechanisms (most likely some form of channel security,
+ such as TSIG, SIG(0), or IPsec).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 17]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+10. DNS Security Document Family
+
+ The DNSSEC document set can be partitioned into several main groups,
+ under the larger umbrella of the DNS base protocol documents.
+
+ The "DNSSEC protocol document set" refers to the three documents
+ which form the core of the DNS security extensions:
+ 1. DNS Security Introduction and Requirements (this document)
+ 2. Resource Records for DNS Security Extensions
+ [I-D.ietf-dnsext-dnssec-records]
+ 3. Protocol Modifications for the DNS Security Extensions
+ [I-D.ietf-dnsext-dnssec-protocol]
+
+ Additionally, any document that would add to, or change the core DNS
+ Security extensions would fall into this category. This includes any
+ future work on the communication between security-aware stub
+ resolvers and upstream security-aware recursive name servers.
+
+ The "Digital Signature Algorithm Specification" document set refers
+ to the group of documents that describe how specific digital
+ signature algorithms should be implemented to fit the DNSSEC resource
+ record format. Each document in this set deals with a specific
+ digital signature algorithm.
+
+ The "Transaction Authentication Protocol" document set refers to the
+ group of documents that deal with DNS message authentication,
+ including secret key establishment and verification. While not
+ strictly part of the DNSSEC specification as defined in this set of
+ documents, this group is noted because of its relationship to DNSSEC.
+
+ The final document set, "New Security Uses", refers to documents that
+ seek to use proposed DNS Security extensions for other security
+ related purposes. DNSSEC does not provide any direct security for
+ these new uses, but may be used to support them. Documents that fall
+ in this category include the use of DNS in the storage and
+ distribution of certificates [RFC2538].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 18]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+11. IANA Considerations
+
+ This overview document introduces no new IANA considerations. Please
+ see [I-D.ietf-dnsext-dnssec-records] for a complete review of the
+ IANA considerations introduced by DNSSEC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 19]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+12. Security Considerations
+
+ This document introduces the DNS security extensions and describes
+ the document set that contains the new security records and DNS
+ protocol modifications. The extensions provide data origin
+ authentication and data integrity using digital signatures over
+ resource record sets.This document discusses the capabilities and
+ limitations of these extensions.
+
+ In order for a security-aware resolver to validate a DNS response,
+ all zones along the path from the trusted starting point to the zone
+ containing the response zones must be signed, and all name servers
+ and resolvers involved in the resolution process must be
+ security-aware, as defined in this document set. A security-aware
+ resolver cannot verify responses originating from an unsigned zone,
+ from a zone not served by a security-aware name server, or for any
+ DNS data which the resolver is only able to obtain through a
+ recursive name server which is not security-aware. If there is a
+ break in the authentication chain such that a security-aware resolver
+ cannot obtain and validate the authentication keys it needs, then the
+ security-aware resolver cannot validate the affected DNS data.
+
+ This document briefly discusses other methods of adding security to a
+ DNS query, such as using a channel secured by IPsec or using a DNS
+ transaction authentication mechanism, but transaction security is not
+ part of DNSSEC per se.
+
+ A non-validating security-aware stub resolver, by definition, does
+ not perform DNSSEC signature validation on its own, and thus is
+ vulnerable both to attacks on (and by) the security-aware recursive
+ name servers which perform these checks on its behalf and also to
+ attacks on its communication with those security-aware recursive name
+ servers. Non-validating security-aware stub resolvers should use some
+ form of channel security to defend against the latter threat. The
+ only known defense against the former threat would be for the
+ security-aware stub resolver to perform its own signature validation,
+ at which point, again by definition, it would no longer be a
+ non-validating security-aware stub resolver.
+
+ DNSSEC does not protect against denial of service attacks. DNSSEC
+ makes DNS vulnerable to a new class of denial of service attacks
+ based on cryptographic operations against security-aware resolvers
+ and security-aware name servers, since an attacker can attempt to use
+ DNSSEC mechanisms to consume a victim's resources. This class of
+ attacks takes at least two forms. An attacker may be able to consume
+ resources in a security-aware resolver's signature validation code by
+ tampering with RRSIG RRs in response messages or by constructing
+ needlessly complex signature chains. An attacker may also be able to
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 20]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+ consume resources in a security-aware name server which supports DNS
+ dynamic update, by sending a stream of update messages that force the
+ security-aware name server to re-sign some RRsets in the zone more
+ frequently than would otherwise be necessary.
+
+ DNSSEC introduces the ability for a hostile party to enumerate all
+ the names in a zone by following the NSEC chain. NSEC RRs assert
+ which names do not exist in a zone by linking from existing name to
+ existing name along a canonical ordering of all the names within a
+ zone. Thus, an attacker can query these NSEC RRs in sequence to
+ obtain all the names in a zone. While not an attack on the DNS
+ itself, this could allow an attacker to map network hosts or other
+ resources by enumerating the contents of a zone. There are non-DNS
+ protocol means of detecting and limiting this attack beyond the scope
+ of this document set.
+
+ DNSSEC introduces significant additional complexity to the DNS, and
+ thus introduces many new opportunities for implementation bugs and
+ misconfigured zones. In particular, enabling DNSSEC signature
+ validation in a resolver may cause entire legitimate zones to become
+ effectively unreachable due to DNSSEC configuration errors or bugs.
+
+ DNSSEC does not provide confidentiality, due to a deliberate design
+ choice.
+
+ DNSSEC does not protect against tampering with unsigned zone data.
+ Non-authoritative data at zone cuts (glue and NS RRs in the parent
+ zone) are not signed. This does not pose a problem when validating
+ the authentication chain, but does mean that the non-authoritative
+ data itself is vulnerable to tampering during zone transfer
+ operations. Thus, while DNSSEC can provide data origin
+ authentication and data integrity for RRsets, it cannot do so for
+ zones, and other mechanisms must be used to protect zone transfer
+ operations.
+
+ Please see [I-D.ietf-dnsext-dnssec-records] and
+ [I-D.ietf-dnsext-dnssec-protocol] for additional security
+ considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 21]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+13. Acknowledgements
+
+ This document was created from the input and ideas of the members of
+ the DNS Extensions Working Group. While explicitly listing everyone
+ who has contributed during the decade during which DNSSEC has been
+ under development would be an impossible task, the editors would
+ particularly like to thank the following people for their
+ contributions to and comments on this document set: Mark Andrews,
+ Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney,
+ Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael
+ Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip
+ Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf
+ Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted
+ Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson,
+ Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik
+ Rozendaal, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, and
+ Brian Wellington.
+
+ No doubt the above list is incomplete. We apologize to anyone we
+ left out.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 22]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+14. References
+
+14.1 Normative References
+
+ [I-D.ietf-dnsext-dnssec-protocol]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
+ progress), May 2004.
+
+ [I-D.ietf-dnsext-dnssec-records]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "Resource Records for DNS Security Extensions",
+ draft-ietf-dnsext-dnssec-records-08 (work in progress),
+ May 2004.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+ 3225, December 2001.
+
+ [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+ message size requirements", RFC 3226, December 2001.
+
+ [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
+ Resource Record (RR)", RFC 3445, December 2002.
+
+14.2 Informative References
+
+ [I-D.ietf-dnsext-dns-threats]
+ Atkins, D. and R. Austein, "Threat Analysis Of The Domain
+ Name System", draft-ietf-dnsext-dns-threats-07 (work in
+ progress), April 2004.
+
+ [I-D.ietf-dnsext-nsec-rdata]
+ Schlyter, J., "KEY RR Secure Entry Point Flag",
+ draft-ietf-dnsext-nsec-rdata-05 (work in progress), March
+ 2004.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 23]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+ Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+ April 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, March 1998.
+
+ [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
+ the Domain Name System (DNS)", RFC 2538, March 1999.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+ [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, November 2000.
+
+ [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
+ Signing Authority", RFC 3008, November 2000.
+
+ [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+ [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+ Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+ [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
+ (RR)", RFC 3658, December 2003.
+
+ [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
+ Signer", RFC 3755, April 2004.
+
+ [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
+ Entry Point Flag", RFC 3757, April 2004.
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 24]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+Authors' Addresses
+
+ Roy Arends
+ Telematica Instituut
+ Drienerlolaan 5
+ 7522 NB Enschede
+ NL
+
+ EMail: roy.arends@telin.nl
+
+
+ Rob Austein
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ EMail: sra@isc.org
+
+
+ Matt Larson
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ EMail: mlarson@verisign.com
+
+
+ Dan Massey
+ USC Information Sciences Institute
+ 3811 N. Fairfax Drive
+ Arlington, VA 22203
+ USA
+
+ EMail: masseyd@isi.edu
+
+
+ Scott Rose
+ National Institute for Standards and Technology
+ 100 Bureau Drive
+ Gaithersburg, MD 20899-8920
+ USA
+
+ EMail: scott.rose@nist.gov
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 25]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 26]
+
+Internet-Draft DNSSEC Introduction and Requirements May 2004
+
+
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 27]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt index 1a9f8aaf..a6f628e3 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt @@ -1,3249 +1,3249 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: August 16, 2004 M. Larson - VeriSign - R. Austein - ISC - D. Massey - USC/ISI - S. Rose - NIST - February 16, 2004 - - - Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-05 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 16, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document is part of a family of documents which describe the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of new resource records and protocol modifications which - add data origin authentication and data integrity to the DNS. This - document describes the DNSSEC protocol modifications. This document - - - -Arends, et al. Expires August 16, 2004 [Page 1] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - defines the concept of a signed zone, along with the requirements for - serving and resolving using DNSSEC. These techniques allow a - security-aware resolver to authenticate both DNS resource records and - authoritative DNS error indications. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 - 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 - 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7 - 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 - 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 - 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9 - 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10 - 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11 - 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11 - 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12 - 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14 - 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16 - 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17 - 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17 - 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19 - 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.2 Signature Verification Support . . . . . . . . . . . . . . . 20 - 4.3 Determining Security Status of Data . . . . . . . . . . . . 21 - 4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 22 - 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 22 - 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . . 22 - 4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 23 - 4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24 - 4.8.1 Handling of the DO Bit . . . . . . . . . . . . . . . . . . . 24 - 4.8.2 Handling of the CD Bit . . . . . . . . . . . . . . . . . . . 24 - - - -Arends, et al. Expires August 16, 2004 [Page 2] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - 4.8.3 Handling of the AD Bit . . . . . . . . . . . . . . . . . . . 24 - 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 26 - 5.1 Special Considerations for Islands of Security . . . . . . . 27 - 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 27 - 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 28 - 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 29 - 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 30 - 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 31 - 5.3.4 Authenticating A Wildcard Expanded RRset Positive - Response . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 32 - 5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 33 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 - 7. Security Considerations . . . . . . . . . . . . . . . . . . 35 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 - Normative References . . . . . . . . . . . . . . . . . . . . 37 - Informative References . . . . . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 - A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40 - B. Example Responses . . . . . . . . . . . . . . . . . . . . . 46 - B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 - B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 47 - B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 48 - B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 49 - B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 50 - B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 50 - B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 51 - B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 52 - C. Authentication Examples . . . . . . . . . . . . . . . . . . 54 - C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 54 - C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 54 - C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 55 - C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 55 - C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 55 - C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 55 - C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 56 - C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 56 - C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 56 - Intellectual Property and Copyright Statements . . . . . . . 57 - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 3] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) are a collection of new resource - records and protocol modifications which add data origin - authentication and data integrity to the DNS. This document defines - the DNSSEC protocol modifications. Section 2 of this document defines - the concept of a signed zone and lists the requirements for zone - signing. Section 3 describes the modifications to authoritative name - server behavior necessary to handle signed zones. Section 4 describes - the behavior of entities which include security-aware resolver - functions. Finally, Section 5 defines how to use DNSSEC RRs to - authenticate a response. - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [RFC1034] and RFC1035 [RFC1035]. - - This document is part of a family of documents which define DNSSEC. - An introduction to DNSSEC and definition of common terms can be found - in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC - resource records can be found in [I-D.ietf-dnsext-dnssec-records]. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. [RFC2119]. - -1.3 Editors' Notes - -1.3.1 Open Technical Issues - -1.3.2 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where no RFC that defines the correct behavior, or if there's - more than one applicable RFC and the definitions conflict, please - post the issue to namedroppers. - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - - - - -Arends, et al. Expires August 16, 2004 [Page 4] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -1.3.3 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to find - the incorrect text quickly. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 5] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -2. Zone Signing - - DNSSEC introduces the concept of signed zones. A signed zone - includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to - the rules specified in Section 2.1, Section 2.2, Section 2.3 and - Section 2.4, respectively. A zone that does not include these - records according to the rules in this section is an unsigned zone. - - DNSSEC requires a change to the definition of the CNAME resource - record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG - and NSEC RRs to appear at the same owner name as a CNAME RR. - -2.1 Including DNSKEY RRs in a Zone - - To sign a zone, the zone's administrator generates one or more - public/private key pairs and uses the private key(s) to sign - authoritative RRsets in the zone. For each private key used to - create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with - the public component stored in the zone. A zone key DNSKEY RR MUST - have the Zone Key bit of the flags RDATA field set to one -- see - Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys - associated with other DNS operations MAY be stored in DNSKEY RRs that - are not marked as zone keys but MUST NOT be used to verify RRSIGs. - - If the zone is delegated and does not wish to act as an island of - security, the zone MUST have at least one DNSKEY RR at the apex to - act as a secure entry point into the zone. This DNSKEY would then be - used to generate a DS RR at the delegating parent (see - [I-D.ietf-dnsext-dnssec-records]). - - DNSKEY RRs MUST NOT appear at delegation points. - -2.2 Including RRSIG RRs in a Zone - - For each authoritative RRset in a signed zone, there MUST be at least - one RRSIG record that meets all of the following requirements: - - o The RRSIG owner name is equal to the RRset owner name; - - o The RRSIG class is equal to the RRset class; - - o The RRSIG Type Covered field is equal to the RRset type; - - o The RRSIG Original TTL field is equal to the TTL of the RRset; - - o The RRSIG RR's TTL is equal to the TTL of the RRset; - - o The RRSIG Labels field is equal to the number of labels in the - - - -Arends, et al. Expires August 16, 2004 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - RRset owner name, not counting the null root label and not - counting the leftmost label if it is a wildcard; - - o The RRSIG Signer's Name field is equal to the name of the zone - containing the RRset; and - - o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a - zone key DNSKEY record at the zone apex. - - The process for constructing the RRSIG RR for a given RRset is - described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have - multiple RRSIG RRs associated with it. - - An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR - would add no value and would create an infinite loop in the signing - process. - - The NS RRset that appears at the zone apex name MUST be signed, but - the NS RRsets that appear at delegation points (that is, the NS - RRsets in the parent zone that delegate the name to the child zone's - name servers) MUST NOT be signed. Glue address RRsets associated with - delegations MUST NOT be signed. - - There MUST be an RRSIG for each RRset using at least one DNSKEY of - each algorithm in the parent zone's DS RRset and each additional - algorithm, if any, in the apex DNSKEY RRset. The apex DNSKEY RRset - itself MUST be signed by each algorithm appearing in the DS RRset. - -2.3 Including NSEC RRs in a Zone - - Each owner name in the zone which has authoritative data or a - delegation point NS RRset MUST have an NSEC resource record. The - process for constructing the NSEC RR for a given name is described in - [I-D.ietf-dnsext-dnssec-records]. - - The TTL value for any NSEC RR SHOULD be the same as the minimum TTL - value field in the zone SOA RR. - - An NSEC record (and its associated RRSIG RRset) MUST NOT be the only - RRset at any particular owner name. That is, the signing process - MUST NOT create NSEC or RRSIG RRs for owner names nodes which were - not the owner name of any RRset before the zone was signed. - - The type bitmap of every NSEC resource record in a signed zone MUST - indicate the presence of both the NSEC record itself and its - corresponding RRSIG record. - - The difference between the set of owner names that require RRSIG - - - -Arends, et al. Expires August 16, 2004 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - records and the set of owner names that require NSEC records is - subtle and worth highlighting. RRSIG records are present at the - owner names of all authoritative RRsets. NSEC records are present at - the owner names of all names for which the signed zone is - authoritative and also at the owner names of delegations from the - signed zone to its children. Neither NSEC nor RRSIG records are - present (in the parent zone) at the owner names of glue address - RRsets. Note, however, that this distinction is for the most part is - only visible during the zone signing process, because NSEC RRsets are - authoritative data, and are therefore signed, thus any owner name - which has an NSEC RRset will have RRSIG RRs as well in the signed - zone. - -2.4 Including DS RRs in a Zone - - The DS resource record establishes authentication chains between DNS - zones. A DS RRset SHOULD be present at a delegation point when the - child zone is signed. The DS RRset MAY contain multiple records, - each referencing a public key in the child zone used to verify the - RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS - RRsets MUST NOT appear at a zone's apex. - - A DS RR SHOULD point to a DNSKEY RR which is present in the child's - apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed - by the corresponding private key. - - The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset - (i.e., the NS RRset from the same zone containing the DS RRset). - - Construction of a DS RR requires knowledge of the corresponding - DNSKEY RR in the child zone, which implies communication between the - child and parent zones. This communication is an operational matter - not covered by this document. - -2.5 Changes to the CNAME Resource Record. - - If a CNAME RRset is present at a name in a signed zone, appropriate - RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that - name for secure dynamic update purposes is also allowed. Other types - MUST NOT be present at that name. - - This is a modification to the original CNAME definition given in - [RFC1034]. The original definition of the CNAME RR did not allow any - other types to coexist with a CNAME record, but a signed zone - requires NSEC and RRSIG RRs for every authoritative name. To resolve - this conflict, this specification modifies the definition of the - CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. - - - - -Arends, et al. Expires August 16, 2004 [Page 8] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -2.6 Example of a Secure Zone - - Appendix A shows a complete example of a small signed zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 9] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -3. Serving - - This section describes the behavior of entities that include - security-aware name server functions. In many cases such functions - will be part of a security-aware recursive name server, but a - security-aware authoritative name server has some of the same - requirements as a security-aware recursive name server does. - Functions specific to security-aware recursive name servers are - described in Section 3.2; functions specific to authoritative servers - are described in Section 3.1. - - The terms "SNAME", "SCLASS", and "STYPE" in the following discussion - are as used in [RFC1034]. - - A security-aware name server MUST support the EDNS0 [RFC2671] message - size extension, MUST support a message size of at least 1220 octets, - and SHOULD support a message size of 4000 octets [RFC3226]. - - A security-aware name server that receives a DNS query that does not - include the EDNS OPT pseudo-RR or that has the DO bit set to zero - MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other - RRset, and MUST NOT perform any of the additional processing - described below. Since the DS RR type has the peculiar property of - only existing in the parent zone at delegation points, DS RRs always - require some special processing, as described in Section 3.1.4.1. - - DNSSEC allocates two new bits in the DNS message header: the CD - (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit - is controlled by resolvers; a security-aware name server MUST copy - the CD bit from a query into the corresponding response. The AD bit - is controlled by name servers; a security-aware name server MUST - ignore the setting of the AD bit in queries. See Section 3.1.6, - Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details - on the behavior of these bits. - -3.1 Authoritative Name Servers - - Upon receiving a relevant query that has the EDNS [RFC2671] OPT - pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative - name server for a signed zone MUST include additional RRSIG, NSEC, - and DS RRs according to the following rules: - - o RRSIG RRs that can be used to authenticate a response MUST be - included in the response according to the rules in Section 3.1.1; - - o NSEC RRs that can be used to provide authenticated denial of - existence MUST be included in the response automatically according - to the rules in Section 3.1.3; - - - -Arends, et al. Expires August 16, 2004 [Page 10] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST - be included in referrals automatically according to the rules in - Section 3.1.4. - - DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 - discusses zone transfer requirements. - -3.1.1 Including RRSIG RRs in a Response - - When responding to a query that has the DO bit set to one, a - security-aware authoritative name server SHOULD attempt to send RRSIG - RRs that a security-aware resolver can use to authenticate the RRsets - in the response. Inclusion of RRSIG RRs in a response is subject to - the following rules: - - o When placing a signed RRset in the Answer section, the name server - MUST also place its RRSIG RRs in the Answer section. The RRSIG - RRs have a higher priority for inclusion than any other RRsets - that may need to be included. If space does not permit inclusion - of these RRSIG RRs, the name server MUST set the TC bit. - - o When placing a signed RRset in the Authority section, the name - server MUST also place its RRSIG RRs in the Authority section. - The RRSIG RRs have a higher priority for inclusion than any other - RRsets that may need to be included. If space does not permit - inclusion of these RRSIG RRs, the name server MUST set the TC bit. - - o When placing a signed RRset in the Additional section, the name - server MUST also place its RRSIG RRs in the Additional section. - If space does not permit inclusion of both the RRset and its - associated RRSIG RRs, the name server MUST NOT set the TC bit - solely because these RRSIG RRs didn't fit. - - -3.1.2 Including DNSKEY RRs In a Response - - When responding to a query that has the DO bit set to one and that - requests the SOA or NS RRs at the apex of a signed zone, a - security-aware authoritative name server for that zone MAY return the - zone apex DNSKEY RRset in the Additional section. In this situation, - the DNSKEY RRset and associated RRSIG RRs have lower priority than - any other information that would be placed in the additional section. - The name server SHOULD NOT include the DNSKEY RRset unless there is - enough space in the response message for both the DNSKEY RRset and - its associated RRSIG RR(s). If there is not enough space to include - these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST - NOT set the TC bit solely because these RRs didn't fit (see Section - 3.1.1). - - - -Arends, et al. Expires August 16, 2004 [Page 11] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -3.1.3 Including NSEC RRs In a Response - - When responding to a query that has the DO bit set to one, a - security-aware authoritative name server for a signed zone MUST - include NSEC RRs in each of the following cases: - - No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>, - but does not contain any RRsets that exactly match <SNAME, SCLASS, - STYPE>. - - Name Error: The zone does not contain any RRsets that match <SNAME, - SCLASS> either exactly or via wildcard name expansion. - - Wildcard Answer: The zone does not contain any RRsets that exactly - match <SNAME, SCLASS> but does contain an RRset that matches - <SNAME, SCLASS, STYPE> via wildcard name expansion. - - Wildcard No Data: The zone does not contain any RRsets that exactly - match <SNAME, SCLASS>, does contain one or more RRsets that match - <SNAME, SCLASS> via wildcard name expansion, but does not contain - any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name - expansion. - - In each of these cases, the name server includes NSEC RRs in the - response to prove that an exact match for <SNAME, SCLASS, STYPE> was - not present in the zone and that the response that the name server is - returning is correct given the data that are in the zone. - -3.1.3.1 Including NSEC RRs: No Data Response - - If the zone contains RRsets matching <SNAME, SCLASS> but contains no - RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST - include the NSEC RR for <SNAME, SCLASS> along with its associated - RRSIG RR(s) in the Authority section of the response (see Section - 3.1.1). If space does not permit inclusion of the NSEC RR or its - associated RRSIG RR(s), the name server MUST set the TC bit (see - Section 3.1.1). - - Since the search name exists, wildcard name expansion does not apply - to this query, and a single signed NSEC RR suffices to prove the - requested RR type does not exist. - -3.1.3.2 Including NSEC RRs: Name Error Response - - If the zone does not contain any RRsets matching <SNAME, SCLASS> - either exactly or via wildcard name expansion, then the name server - MUST include the following NSEC RRs in the Authority section, along - with their associated RRSIG RRs: - - - -Arends, et al. Expires August 16, 2004 [Page 12] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o An NSEC RR proving that there is no exact match for <SNAME, - SCLASS>; and - - o An NSEC RR proving that the zone contains no RRsets that would - match <SNAME, SCLASS> via wildcard name expansion. - - In some cases a single NSEC RR may prove both of these points, in - that case the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - Note that this form of response includes cases in which SNAME - corresponds to an empty non-terminal name within the zone (a name - which is not the owner name for any RRset but which is the parent - name of one or more RRsets). - -3.1.3.3 Including NSEC RRs: Wildcard Answer Response - - If the zone does not contain any RRsets which exactly match <SNAME, - SCLASS> but does contain an RRset which matches <SNAME, SCLASS, - STYPE> via wildcard name expansion, the name server MUST include the - wildcard-expanded answer and the corresponding wildcard-expanded - RRSIG RRs in the Answer section, and MUST include in the Authority - section an NSEC RR and associated RRSIG RR(s) proving that the zone - does not contain a closer match for <SNAME, SCLASS>. If space does - not permit inclusion of the answer, NSEC and RRSIG RRs, the name - server MUST set the TC bit (see Section 3.1.1). - -3.1.3.4 Including NSEC RRs: Wildcard No Data Response - - This case is a combination of the previous cases. The zone does not - contain an exact match for <SNAME, SCLASS>, and while the zone does - contain RRsets which match <SNAME, SCLASS> via wildcard expansion, - none of those RRsets match STYPE. The name server MUST include the - following NSEC RRs in the Authority section, along with their - associated RRSIG RRs: - - o An NSEC RR proving that there are no RRsets matching STYPE at the - wildcard owner name which matched <SNAME, SCLASS> via wildcard - expansion; and - - o An NSEC RR proving that there are no RRsets in the zone which - - - -Arends, et al. Expires August 16, 2004 [Page 13] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - would have been a closer match for <SNAME, SCLASS>. - - In some cases a single NSEC RR may prove both of these points, in - which case the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - -3.1.3.5 Finding The Right NSEC RRs - - As explained above, there are several situations in which a - security-aware authoritative name server needs to locate an NSEC RR - which proves that a particular SNAME does not exist. Locating such - an NSEC RR within an authoritative zone is relatively simple, at - least in concept. The following discussion assumes that the name - server is authoritative for the zone which would have held the - nonexistent SNAME. The algorithm below is written for clarity, not - efficiency. - - To find the NSEC which proves that name N does not exist in the zone - Z which would have held it, construct sequence S consisting of every - name in Z, sorted into canonical order - [I-D.ietf-dnsext-dnssec-records]. Find the name M which would have - immediately preceded N in S if N had existed. M is the owner name of - the NSEC RR which proves that N does not exist. - - The algorithm for finding the NSEC RR which proves that a given name - is not covered by any applicable wildcard is similar, but requires an - extra step. More precisely, the algorithm for finding the NSEC - proving that the applicable wildcard name does not exist is precisely - the same as the algorithm for finding the NSEC RR which proves that - any other name does not exist: the part that's missing is how to - determine the name of the nonexistent applicable wildcard. In - practice, this is easy, because the authoritative name server has - already checked for the presence of precisely this wildcard name as - part of step (1)(c) of the normal lookup algorithm described in - Section 4.3.2 of [RFC1034]. - -3.1.4 Including DS RRs In a Response - - When responding to a query which has the DO bit set to one, a - security-aware authoritative name server returning a referral - includes DNSSEC data along with the NS RRset. - - - -Arends, et al. Expires August 16, 2004 [Page 14] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - If a DS RRset is present at the delegation point, the name server - MUST return both the DS RRset and its associated RRSIG RR(s) in the - Authority section along with the NS RRset. The name server MUST - place the NS RRset before the DS RRset and its associated RRSIG - RR(s). - - If no DS RRset is present at the delegation point, the name server - MUST return both the NSEC RR which proves that the DS RRset is not - present and the NSEC RR's associated RRSIG RR(s) along with the NS - RRset. The name server MUST place the NS RRset before the NSEC RRset - and its associated RRSIG RR(s). - - Including these DS, NSEC, and RRSIG RRs increases the size of - referral messages, and may cause some or all glue RRs to be omitted. - If space does not permit inclusion of the DS or NSEC RRset and - associated RRSIG RRs, the name server MUST set the TC bit (see - Section 3.1.1). - -3.1.4.1 Responding to Queries for DS RRs - - The DS resource record type is unusual in that it appears only on the - parent zone's side of a zone cut. For example, the DS RRset for the - delegation of "foo.example" is stored in the "example" zone rather - than in the "foo.example" zone. This requires special processing - rules for both name servers and resolvers, since the name server for - the child zone is authoritative for the name at the zone cut by the - normal DNS rules but the child zone does not contain the DS RRset. - - A security-aware resolver sends queries to the parent zone when - looking for a needed DS RR at a delegation point (see Section 4.2). - However, special rules are necessary to avoid confusing - security-oblivious resolvers which might become involved in - processing such a query (for example, in a network configuration that - forces a security-aware resolver to channel its queries through a - security-oblivious recursive name server). The rest of this section - describes how a security-aware name server processes DS queries in - order to avoid this problem. - - The need for special processing by a security-aware name server only - arises when all the following conditions are met: - - o the name server has received a query for the DS RRset at a zone - cut; and - - o the name server is authoritative for the child zone; and - - o the name server is not authoritative for the parent zone; and - - - - -Arends, et al. Expires August 16, 2004 [Page 15] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o the name server does not offer recursion. - - In all other cases, the name server either has some way of obtaining - the DS RRset or could not have been expected to have the DS RRset - even by the pre-DNSSEC processing rules, so the name server can - return either the DS RRset or an error response according to the - normal processing rules. - - If all of the above conditions are met, however, the name server is - authoritative for SNAME but cannot supply the requested RRset. In - this case, the name server MUST return an authoritative "no data" - response showing that the DS RRset does not exist in the child zone's - apex. See Appendix B.8 for an example of such a response. - -3.1.5 Responding to Queries for Type AXFR or IXFR - - DNSSEC does not change the DNS zone transfer process. A signed zone - will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these - records have no special meaning with respect to a zone transfer - operation, and these RRs are treated as any other resource record - type. - - An authoritative name server is not required to verify that a zone is - properly signed before sending or accepting a zone transfer. - However, an authoritative name server MAY choose to reject the entire - zone transfer if the zone fails meets any of the signing requirements - described in Section 2. The primary objective of a zone transfer is - to ensure that all authoritative name servers have identical copies - of the zone. An authoritative name server which chooses to perform - its own zone validation MUST NOT selectively reject some RRs and - accept others. - - DS RRsets appear only on the parental side of a zone cut and are - authoritative data in the parent zone. As with any other - authoritative RRset, the DS RRset MUST be included in zone transfers - of the zone in which the RRset is authoritative data: in the case of - the DS RRset, this is the parent zone. - - NSEC RRs appear in both the parent and child zones at a zone cut, and - are authoritative data in both the parent and child zones. The - parental and child NSEC RRs at a zone cut are never identical to each - other, since the NSEC RR in the child zone's apex will always - indicate the presence of the child zone's SOA RR while the parental - NSEC RR at the zone cut will never indicate the presence of an SOA - RR. As with any other authoritative RRs, NSEC RRs MUST be included - in zone transfers of the zone in which they are authoritative data: - the parental NSEC RR at a zone cut MUST be included zone transfers of - the parent zone, while the NSEC at the zone apex of the child zone - - - -Arends, et al. Expires August 16, 2004 [Page 16] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - MUST be included in zone transfers of the child zone. - - RRSIG RRs appear in both the parent and child zones at a zone cut, - and are authoritative in whichever zone contains the authoritative - RRset for which the RRSIG RR provides the signature. That is, the - RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be - authoritative in the parent zone, while the RRSIG for any RRset in - the child zone's apex will be authoritative in the child zone. As - with any other authoritative RRs, RRSIG RRs MUST be included in zone - transfers of the zone in which they are authoritative data. - -3.1.6 The AD and CD Bits in an Authoritative Response - - The CD and AD bits are designed to be used in communication between - security-aware resolvers and security-aware recursive name servers. - This bits are for the most part not relevant to query processing by - security-aware authoritative name servers. - - Since a security-aware name server does not perform signature - validation for authoritative data during query processing even when - the CD bit is set to zero, a security-aware name server SHOULD ignore - the setting of the CD bit when composing an authoritative response. - - A security-aware name server MUST NOT set the AD bit in a response - unless the name server considers all RRsets in the Answer and - Authority sections of the response to be authentic. A security-aware - name server's local policy MAY consider data from an authoritative - zone to be authentic without further validation, but the name server - MUST NOT do so unless the name server obtained the authoritative zone - via secure means (such as a secure zone transfer mechanism), and MUST - NOT do so unless this behavior has been configured explicitly. - - A security-aware name server which supports recursion MUST follow the - rules for the CD and AD bits given in Section 3.2 when generating a - response that involves data obtained via recursion. - -3.2 Recursive Name Servers - - As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware - recursive name server is an entity which acts in both the - security-aware name server and security-aware resolver roles. This - section uses the terms "name server side" and "resolver side" to - refer to the code within a security-aware recursive name server which - implements the security-aware name server role and the code which - implements the security-aware resolver role, respectively. - - The resolver side follows the usual rules for caching and negative - caching which would apply to any security-aware resolver. - - - -Arends, et al. Expires August 16, 2004 [Page 17] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -3.2.1 The DO bit - - The resolver side of a security-aware recursive name server MUST set - the DO bit when sending requests, regardless of the state of the DO - bit in the initiating request received by the name server side. If - the DO bit in an initiating query is not set, the name server side - MUST strip any authenticating DNSSEC RRs from the response, but MUST - NOT strip any DNSSEC RRs that the initiating query explicitly - requested. - -3.2.2 The CD bit - - The CD bit exists in order to allow a security-aware resolver to - disable signature validation in a security-aware name server's - processing of a particular query. - - The name server side MUST copy the setting of the CD bit from a query - to the corresponding response. - - The name server side of a security-aware recursive name server MUST - pass the sense of the CD bit to the resolver side along with the rest - of an initiating query, so that the resolver side will know whether - or not it is required to verify the response data it returns to the - name server side. If the CD bit is set to one, it indicates that the - originating resolver is willing to perform whatever authentication - its local policy requires, thus the resolver side of the recursive - name server need not perform authentication on the RRsets in the - response. When the CD bit is set to one the recursive name server - SHOULD, if possible, return the requested data to the originating - resolver even if the recursive name server's local authentication - policy would reject the records in question. That is, by setting the - CD bit, the originating resolver has indicated that it takes - responsibility for performing its own authentication, and the - recursive name server should not interfere. - - If the resolver side implements a BAD cache (see Section 4.7) and the - name server side receives a query which matches an entry in the - resolver side's BAD cache, the name server side's response depends on - the sense of the CD bit in the original query. If the CD bit is set, - the name server side SHOULD return the data from the BAD cache; if - the CD bit is not set, the name server side MUST return RCODE 2 - (server failure). - -3.2.3 The AD bit - - The name server side of a security-aware recursive name server MUST - NOT set the AD bit in a response unless the name server considers all - RRsets in the Answer and Authority sections of the response to be - - - -Arends, et al. Expires August 16, 2004 [Page 18] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - authentic, and SHOULD set the AD bit if and only if the resolver side - considers all RRsets in the Answer section and any relevant negative - response RRs in the Authority section to be authentic. The resolver - side MUST follow the procedure described in Section 5 to determine - whether the RRs in question are authentic. - -3.3 Example DNSSEC Responses - - See Appendix B for example response packets. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 19] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -4. Resolving - - This section describes the behavior of entities which include - security-aware resolver functions. In many cases such functions will - be part of a security-aware recursive name server, but a stand-alone - security-aware resolver has many of the same requirements. Functions - specific to security-aware recursive name servers are described in - Section 3.2. - -4.1 EDNS Support - - A security-aware resolver MUST include an EDNS [RFC2671] OPT - pseudo-RR with the DO [RFC3225] bit set to one when sending queries. - - A security-aware resolver MUST support a message size of at least - 1220 octets, SHOULD support a message size of 4000 octets, and MUST - advertise the supported message size using the "sender's UDP payload - size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST - handle fragmented UDP packets correctly regardless of whether any - such fragmented packets were received via IPv4 or IPv6. Please see - [RFC3226] for discussion of these requirements. - -4.2 Signature Verification Support - - A security-aware resolver MUST support the signature verification - mechanisms described in Section 5, and MUST apply them to every - received response except when: - - o The security-aware resolver is part of a security-aware recursive - name server, and the response is the result of recursion on behalf - of a query received with the CD bit set; - - o The response is the result of a query generated directly via some - form of application interface which instructed the security-aware - resolver not to perform validation for this query; or - - o Validation for this query has been disabled by local policy. - - A security-aware resolver's support for signature verification MUST - include support for verification of wildcard owner names. - - Editors' note: The rest of this section is expected to change once - the WG reaches closure on Q-23. - - A security-aware resolver MUST attempt to retrieve missing DS, - DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these - RRs in order to perform signature verification. - - - - -Arends, et al. Expires August 16, 2004 [Page 20] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - A security-aware resolver MUST attempt to retrieve a missing NSEC RR - which the resolver needs to authenticate a NODATA response. In - general it is not possible for a resolver to retrieve missing NSEC - RRs, since the resolver will have no way of knowing the owner name of - the missing NSEC RR, but in the specific case of a NODATA response, - the resolver may know the name of the missing NSEC RR, and in such - cases must therefore attempt to retrieve it. - - When attempting to retrieve missing NSEC RRs which reside on the - parental side at a zone cut, a security-aware iterative-mode resolver - MUST query the name servers for the parent zone, not the child zone. - - When attempting to retrieve a missing DS, a security-aware - iterative-mode resolver MUST query the name servers for the parent - zone, not the child zone. As explained in Section 3.1.4.1, - security-aware name servers need to apply special processing rules to - handle the DS RR, and in some situations the resolver may also need - to apply special rules to locate the name servers for the parent zone - if the resolver does not already have the parent's NS RRset. To - locate the parent NS RRset, the resolver can start with the - delegation name, strip off the leftmost label, and query for an NS - RRset by that name; if no NS RRset is present at that name, the - resolver then strips of the leftmost remaining label and retries the - query for that name, repeating this process of walking up the tree - until it either finds the NS RRset or runs out of labels. - - Editors' note: This algorithm could easily be read as an - invitation to careless implementors to hammer the root zone - servers. Better wording would be welcome. - - -4.3 Determining Security Status of Data - - Editors' note: This section is waiting for resolution of Q-28. - - A security-aware resolver MUST be able to determine whether or not it - should expect a particular RRset to be signed. More precisely, a - security-aware resolver must be able to distinguish between three - cases: - - 1. An RRset for which the resolver is able to build a chain of - signed DNSKEY and DS RRs from a trusted security anchor to the - RRset. In this case, the RRset should be signed, and is subject - to signature validation as described above. - - 2. An RRset for which the resolver knows that it has no chain of - signed DNSKEY and DS RRs from any trusted starting point to the - RRset. This can occur when the target RRset lies in an unsigned - - - -Arends, et al. Expires August 16, 2004 [Page 21] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - zone or in a descendent of an unsigned zone. In this case, the - RRset may or may not be signed, but the resolver will not be able - to verify the signature. - - 3. An RRset for which the resolver is not able to determine whether - or not the RRset should be signed, because the resolver is not - able to obtain the necessary DNSSEC RRs. This can occur when the - security-aware resolver is not able to contact security-aware - name servers for the relevant zones. - - -4.4 Preconfigured Public Keys - - A security-aware resolver MUST be capable of being preconfigured with - at least one trusted public key or DS RR, and SHOULD be capable of - being preconfigured with multiple trusted public keys or DS RRs. - Since a security-aware resolver will not be able to validate - signatures without such a preconfigured trusted key, the resolver - SHOULD have some reasonably robust mechanism for obtaining such keys - when it boots; examples of such a mechanism would be some form of - non-volatile storage (such as a disk drive) or some form of trusted - local network configuration mechanism. - -4.5 Response Caching - - Editors' note: RIPE "last call" workshop felt that the WG needs to - reexamine and discuss this section. - - A security-aware resolver SHOULD cache each response as a single - atomic entry containing the entire answer, including the named RRset - and any associated DNSSEC RRs. The resolver SHOULD discard the - entire atomic entry when any of the RRs contained in it expire. In - most cases the appropriate cache index for the atomic entry will be - the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response - form described in Section 3.1.3.2 the appropriate cache index will be - the double <QNAME,QCLASS>. - -4.6 Handling of the CD and AD bits - - A security-aware resolver MAY set the CD bit in a query to one in - order to indicate that the resolver takes responsibility for - performing whatever authentication its local policy requires on the - RRsets in the response. See Section 3.2 for the effect this bit has - on the behavior of security-aware recursive name servers. - - A security-aware resolver MUST zero the AD bit when composing query - messages to protect against buggy name servers which blindly copy - header bits which they do not understand from the query message to - - - -Arends, et al. Expires August 16, 2004 [Page 22] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - the response message. - - A resolver MUST disregard the meaning of the CD and AD bits in a - response unless the response was obtained using a secure channel or - the resolver was specifically configured to regard the message header - bits without using a secure channel. - -4.7 Rate Limiting - - A security-aware resolver SHOULD NOT cache data with invalid - signatures under normal circumstances. However, a security-aware - resolver SHOULD take steps to rate limit the number of identical - queries that it generates if signature validation of the responses - fails repeatedly. - - Conceptually, this is similar in some respects to negative caching - [RFC2308], but since the resolver has no way of obtaining an - appropriate caching TTL from received data in this case, the TTL will - have to be set by the implementation. This document refers to the - data retained as part of such a rate limiting mechanism as the "BAD - cache". - - A security-aware resolver MAY chose to retain RRsets for which - signature validation has failed in its BAD cache, but MUST NOT return - such RRsets from its BAD cache unless both of the following - conditions are met: - - o The resolver has recently generated enough queries identical to - this one that the resolver is suppressing queries for this <QNAME, - QTYPE, QCLASS>; and - - o The resolver is not required to validate the signatures of the - RRsets in question under the rules given in Section 4 of this - document. - - The intent of the above rule is to provide the raw data to clients - which are capable of performing their own signature verification - checks while protecting clients which depend on this resolver to - perform such checks. Several of the possible reasons why signature - validation might fail involve conditions which may not apply equally - to this resolver and the client which invoked it: for example, this - resolver's clock may be set incorrectly, or the client may have - knowledge of a relevant island of security which this resolver does - not share. In such cases, "protecting" a client which is capable of - performing its own signature validation from ever seeing the "bad" - data does not help the client. - - - - - -Arends, et al. Expires August 16, 2004 [Page 23] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -4.8 Stub resolvers - - A security-aware stub resolver MUST support the DNSSEC RR types, at - least to the extent of not mishandling responses just because they - contain DNSSEC RRs. - -4.8.1 Handling of the DO Bit - - A non-validating security-aware stub resolver MAY include the DNSSEC - RRs returned by a security-aware recursive name server as part of the - data that the stub resolver hands back to the application which - invoked it but is not required to do so. A non-validating stub - resolver that wishes to do this will need to set the DO bit in - receive DNSSEC RRs from the recursive name server. - - A validating security-aware stub resolver MUST set the DO bit, since - otherwise it will not receive the DNSSEC RRs it needs to perform - signature validation. - -4.8.2 Handling of the CD Bit - - A non-validating security-aware stub resolver SHOULD NOT set the CD - bit when sending queries unless requested by the application layer, - since by definition, a non-validating stub resolver depends on the - security-aware recursive name server to perform validation on its - behalf. - - A validating security-aware stub resolver SHOULD set the CD bit, - since otherwise the security-aware recursive name server will answer - the query using the name server's local policy, which may prevent the - stub resolver from receiving data which would be acceptable to the - stub resolver's local policy. - -4.8.3 Handling of the AD Bit - - A non-validating security-aware stub resolver MAY chose to examine - the setting of the AD bit in response messages that it receives in - order to determine whether the security-aware recursive name server - which sent the response claims to have cryptographically verified the - data in the Answer and Authority sections of the response message. - Note, however, that the responses received by a security-aware stub - resolver are heavily dependent on the local policy of the - security-aware recursive name server, so as a practical matter there - may be little practical value to checking the status of the AD bit - except perhaps as a debugging aid. In any case, a security-aware - stub resolver MUST NOT place any reliance on signature validation - allegedly performed on its behalf except when the security-aware stub - resolver obtained the data in question from a trusted security-aware - - - -Arends, et al. Expires August 16, 2004 [Page 24] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - recursive name server via a secure channel. - - A validating security-aware stub resolver SHOULD NOT examine the - setting of the AD bit in response messages, since, by definition, the - stub resolver performs its own signature validation regardless of the - setting of the AD bit. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 25] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -5. Authenticating DNS Responses - - In order to use DNSSEC RRs for authentication, a security-aware - resolver requires preconfigured knowledge of at least one - authenticated DNSKEY or DS RR. The process for obtaining and - authenticating this initial DNSKEY or DS RR is achieved via some - external mechanism. For example, a resolver could use some off-line - authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR - that identifies and authenticates a zone's DNSKEY RR. The remainder - of this section assumes that the resolver has somehow obtained an - initial set of authenticated DNSKEY RRs. - - An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY - RRset. To authenticate an apex DNSKEY RRset using an initial key, - the resolver MUST: - - 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag - (DNSKEY RDATA bit 7) set to one. - - 2. Verify that there is some RRSIG RR that covers the apex DNSKEY - RRset, and that the combination of the RRSIG RR and the initial - DNSKEY RR authenticates the DNSKEY RRset. The process for using - an RRSIG RR to authenticate an RRset is described in Section 5.3. - - Once the resolver has authenticated the apex DNSKEY RRset using an - initial DNSKEY RR, delegations from that zone can be authenticated - using DS RRs. This allows a resolver to start from an initial key, - and use DS RRsets to proceed recursively down the DNS tree obtaining - other apex DNSKEY RRsets. If the resolver were preconfigured with a - root DNSKEY RR, and if every delegation had a DS RR associated with - it, then the resolver could obtain and validate any apex DNSKEY - RRset. The process of using DS RRs to authenticate referrals is - described in Section 5.2. - - Once the resolver has authenticated a zone's apex DNSKEY RRset, - Section 5.3 shows how the resolver can use DNSKEY RRs in the apex - DNSKEY RRset and RRSIG RRs from the zone to authenticate any other - RRsets in the zone. Section 5.4 shows how the resolver can use - authenticated NSEC RRsets from the zone to prove that an RRset is not - present in the zone. - - When a resolver indicates support for DNSSEC (by setting the DO bit), - a security-aware name server should attempt to provide the necessary - DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). - However, a security-aware resolver may still receive a response that - that lacks the appropriate DNSSEC RRs, whether due to configuration - issues such as a security-oblivious recursive name server that - - - -Arends, et al. Expires August 16, 2004 [Page 26] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - accidentally interfere with DNSSEC RRs or due to a deliberate attack - in which an adversary forges a response, strips DNSSEC RRs from a - response, or modifies a query so that DNSSEC RRs appear not to be - requested. The absence of DNSSEC data in a response MUST NOT by - itself be taken as an indication that no authentication information - exists. - - A resolver SHOULD expect authentication information from signed - zones. A resolver SHOULD believe that a zone is signed if the - resolver has been configured with public key information for the - zone, or if the zone's parent is signed and the delegation from the - parent contains a DS RRset. - -5.1 Special Considerations for Islands of Security - - Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed - zones for which it is not possible to construct an authentication - chain to the zone from its parent. Validating signatures within an - island of security requires the validator to have some other means of - obtaining an initial authenticated zone key for the island. If a - validator cannot obtain such a key, it will have to choose whether to - accept the unvalidated responses or not based on local policy. - - All the normal processes for validating responses apply to islands of - security. The only difference between normal validation and - validation within an island of security is in how the validator - obtains a starting point for the authentication chain. - -5.2 Authenticating Referrals - - Once the apex DNSKEY RRset for a signed parent zone has been - authenticated, DS RRsets can be used to authenticate the delegation - to a signed child zone. A DS RR identifies a DNSKEY RR in the child - zone's apex DNSKEY RRset, and contains a cryptographic digest of the - child zone's DNSKEY RR. A strong cryptographic digest algorithm - ensures that an adversary can not easily generate a DNSKEY RR that - matches the digest. Thus, authenticating the digest allows a - resolver to authenticate the matching DNSKEY RR. The resolver can - then use this child DNSKEY RR to authenticate the entire child apex - DNSKEY RRset. - - Given a DS RR for a delegation, the child zone's apex DNSKEY RRset - can be authenticated if all of the following hold: - - o The DS RR has been authenticated using some DNSKEY RR in the - parent's apex DNSKEY RRset (see Section 5.3); - - o The Algorithm and Key Tag in the DS RR match the Algorithm field - - - -Arends, et al. Expires August 16, 2004 [Page 27] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - and the key tag of a DNSKEY RR in the child zone's apex DNSKEY - RRset that, when hashed using the digest algorithm specified in - the DS RR's Digest Type field, results in a digest value that - matches the Digest field of the DS RR; and - - o The matching DNSKEY RR in the child zone has the Zone Flag bit set - to one, the corresponding private key has signed the child zone's - apex DNSKEY RRset, and the resulting RRSIG RR authenticates the - child zone's apex DNSKEY RRset. - - If the referral from the parent zone did not contain a DS RRset, the - response should have included a signed NSEC RRset proving that no DS - RRset exists for the delegated name (see Section 3.1.4). A - security-aware resolver MUST query the name servers for the parent - zone for the DS RRset if the referral includes neither a DS RRset nor - a NSEC RRset proving that the DS RRset does not exist (see Section - 4). - - If the resolver authenticates an NSEC RRset that proves that no DS - RRset is present for this zone, then there is no authentication path - leading from the parent to the child. If the resolver has an initial - DNSKEY or DS RR that belongs to the child zone or to any delegation - below the child zone, this initial DNSKEY or DS RR MAY be used to - re-establish an authentication path. If no such initial DNSKEY or DS - RR exists, the resolver can not authenticate RRsets in or below the - child zone. - - Note that, for a signed delegation, there are two NSEC RRs associated - with the delegated name. One NSEC RR resides in the parent zone, and - can be used to prove whether a DS RRset exists for the delegated - name. The second NSEC RR resides in the child zone, and identifies - which RRsets are present at the apex of the child zone. The parent - NSEC RR and child NSEC RR can always be distinguished, since the SOA - bit will be set in the child NSEC RR and clear in the parent NSEC RR. - A security-aware resolver MUST use the parent NSEC RR when attempting - to prove that a DS RRset does not exist. - - If the resolver does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver will not be able to verify - the authentication path to the child zone. In this case, the - resolver SHOULD treat the child zone as if it were unsigned. - -5.3 Authenticating an RRset Using an RRSIG RR - - A resolver can use an RRSIG RR and its corresponding DNSKEY RR to - attempt to authenticate RRsets. The resolver first checks the RRSIG - RR to verify that it covers the RRset, has a valid time interval, and - identifies a valid DNSKEY RR. The resolver then constructs the - - - -Arends, et al. Expires August 16, 2004 [Page 28] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - canonical form of the signed data by appending the RRSIG RDATA - (excluding the Signature Field) with the canonical form of the - covered RRset. Finally, resolver uses the public key and signature - to authenticate the signed data. Section 5.3.1, Section 5.3.2, and - Section 5.3.3 describe each step in detail. - -5.3.1 Checking the RRSIG RR Validity - - A security-aware resolver can use an RRSIG RR to authenticate an - RRset if all of the following conditions hold: - - o The RRSIG RR and the RRset MUST have the same owner name and the - same class; - - o The RRSIG RR's Signer's Name field MUST be the name of the zone - that contains the RRset; - - o The RRSIG RR's Type Covered field MUST equal the RRset's type; - - o The number of labels in the RRset owner name MUST be greater than - or equal to the value in the RRSIG RR's Labels field; - - o The resolver's notion of the current time MUST be less than or - equal to the time listed in the RRSIG RR's Expiration field; - - o The resolver's notion of the current time MUST be greater than or - equal to the time listed in the RRSIG RR's Inception field; - - o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST - match the owner name, algorithm, and key tag for some DNSKEY RR in - the zone's apex DNSKEY RRset; - - o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY - RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) - set to one. - - It is possible for more than one DNSKEY RR to match the conditions - above. In this case, the resolver can not predetermine which DNSKEY - RR to use to authenticate the signature, MUST try each matching - DNSKEY RR until the resolver has either validated the signature or - has run out of matching public keys to try. - - Note that this authentication process is only meaningful if the - resolver authenticates the DNSKEY RR before using it to validate - signatures. The matching DNSKEY RR is considered to be authentic if: - - o The apex DNSKEY RRset containing the DNSKEY RR is considered - authentic; or - - - -Arends, et al. Expires August 16, 2004 [Page 29] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, - and the DNSKEY RR either matches an authenticated DS RR from the - parent zone or matches a DS RR or DNSKEY RR that the resolver has - been preconfigured to believe to be authentic. - - -5.3.2 Reconstructing the Signed Data - - Once the RRSIG RR has met the validity requirements described in - Section 5.3.1, the resolver needs to reconstruct the original signed - data. The original signed data includes RRSIG RDATA (excluding the - Signature field) and the canonical form of the RRset. Aside from - being ordered, the canonical form of the RRset might also differ from - the received RRset due to DNS name compression, decremented TTLs, or - wildcard expansion. The resolver should use the following to - reconstruct the original signed data: - - signed_data = RRSIG_RDATA | RR(1) | RR(2)... where - - "|" denotes concatenation - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signature field excluded and the Signer's Name - in canonical form. - - RR(i) = name | class | type | OrigTTL | RDATA length | RDATA - - name is calculated according to the function below - - class is the RRset's class - - type is the RRset type and all RRs in the class - - OrigTTL is the value from the RRSIG Original TTL field - - All names in the RDATA field are in canonical form - - The set of all RR(i) is sorted into canonical order. - - To calculate the name: - let rrsig_labels = the value of the RRSIG Labels field - - let fqdn = RRset's fully qualified domain name in - canonical form - - let fqdn_labels = Label count of the fqdn above. - - if rrsig_labels = fqdn_labels, - - - -Arends, et al. Expires August 16, 2004 [Page 30] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - name = fqdn - - if rrsig_labels < fqdn_labels, - name = "*." | the rightmost rrsig_label labels of the - fqdn - - if rrsig_labels > fqdn_labels - the RRSIG RR did not pass the necessary validation - checks and MUST NOT be used to authenticate this - RRset. - - The canonical forms for names and RRsets are defined in - [I-D.ietf-dnsext-dnssec-records]. - - NSEC RRsets at a delegation boundary require special processing. - There are two distinct NSEC RRsets associated with a signed delegated - name. One NSEC RRset resides in the parent zone, and specifies which - RRset are present at the parent zone. The second NSEC RRset resides - at the child zone, and identifies which RRsets are present at the - apex in the child zone. The parent NSEC RRset and child NSEC RRset - can always be distinguished since only the child NSEC RRs will - specify an SOA RRset exists at the name. When reconstructing the - original NSEC RRset for the delegation from the parent zone, the NSEC - RRs MUST NOT be combined with NSEC RRs from the child zone, and when - reconstructing the original NSEC RRset for the apex of the child - zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent - zone. - - Note also that each of the two NSEC RRsets at a delegation point has - a corresponding RRSIG RR with an owner name matching the delegated - name, and each of these RRSIG RRs is authoritative data associated - with the same zone that contains the corresponding NSEC RRset. If - necessary, a resolver can tell these RRSIG RRs apart by checking the - Signer's Name field. - -5.3.3 Checking the Signature - - Once the resolver has validated the RRSIG RR as described in Section - 5.3.1 and reconstructed the original signed data as described in - Section 5.3.2, the resolver can attempt to use the cryptographic - signature to authenticate the signed data, and thus (finally!) - authenticate the RRset. - - The Algorithm field in the RRSIG RR identifies the cryptographic - algorithm used to generate the signature. The signature itself is - contained in the Signature field of the RRSIG RDATA, and the public - key used to verify the signature is contained in the Public Key field - of the matching DNSKEY RR(s) (found in Section 5.3.1). - - - -Arends, et al. Expires August 16, 2004 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types, - and provides pointers to the documents that define each algorithm's - use. - - Note that it is possible for more than one DNSKEY RR to match the - conditions in Section 5.3.1. In this case, the resolver can only - determine which DNSKEY RR by trying each matching public key until - the resolver either succeeds in validating the signature or runs out - of keys to try. - - If the Labels field of the RRSIG RR is not equal to the number of - labels in the RRset's fully qualified owner name, then the RRset is - either invalid or the result of wildcard expansion. The resolver - MUST verify that wildcard expansion was applied properly before - considering the RRset to be authentic. Section 5.3.4 describes how - to determine whether a wildcard was applied properly. - - If other RRSIG RRs also cover this RRset, the local resolver security - policy determines whether the resolver also needs to test these RRSIG - RRs, and determines how to resolve conflicts if these RRSIG RRs lead - to differing results. - - If the resolver accepts the RRset as authentic, the resolver MUST set - the TTL of the RRSIG RR and each RR in the authenticated RRset to a - value no greater than the minimum of: - - o The RRset's TTL as received in the response; - - o The RRSIG RR's TTL as received in the response; and - - o The value in the RRSIG RR's Original TTL field. - - -5.3.4 Authenticating A Wildcard Expanded RRset Positive Response - - If the number of labels in an RRset's owner name is greater than the - Labels field of the covering RRSIG RR, then the RRset and its - covering RRSIG RR were created as a result of wildcard expansion. - Once the resolver has verified the signature as described in Section - 5.3, the resolver must take additional steps to verify the - non-existence of an exact match or closer wildcard match for the - query. Section 5.4 discusses these steps. - - Note that the response received by the resolver should include all - NSEC RRs needed to authenticate the response (see Section 3.1.3). - -5.4 Authenticated Denial of Existence - - - - -Arends, et al. Expires August 16, 2004 [Page 32] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - A resolver can use authenticated NSEC RRs to prove that an RRset is - not present in a signed zone. Security-aware name servers should - automatically include any necessary NSEC RRs for signed zones in - their responses to security-aware resolvers. - - Security-aware resolvers MUST first authenticate NSEC RRsets - according to the standard RRset authentication rules described in - Section 5.3, then apply the NSEC RRsets as follows: - - o If the requested RR name matches the owner name of an - authenticated NSEC RR, then the NSEC RR's type bit map field lists - all RR types present at that owner name, and a resolver can prove - that the requested RR type does not exist by checking for the RR - type in the bit map. If the number of labels in an authenticated - NSEC RR's owner name equals the Labels field of the covering RRSIG - RR, then the existence of the NSEC RR proves that wildcard - expansion could not have been used to match the request. - - o If the requested RR name would appear after an authenticated NSEC - RR's owner name and before the name listed in that NSEC RR's Next - Domain Name field according to the canonical DNS name order - defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with - the requested name exist in the zone. However, it is possible - that a wildcard could be used to match the requested RR owner name - and type, so proving that the requested RRset does not exist also - requires proving that no possible wildcard RRset exists that could - have been used to generate a positive response. - - To prove non-existence of an RRset, the resolver must be able to - verify both that the queried RRset does not exist and that no - relevant wildcard RRset exists. Proving this may require more than - one NSEC RRset from the zone. If the complete set of necessary NSEC - RRsets is not present in a response (perhaps due to message - truncation), then a security-aware resolver MUST resend the query in - order to attempt to obtain the full collection of NSEC RRs necessary - to verify non-existence of the requested RRset. As with all DNS - operations, however, the resolver MUST bound the work it puts into - answering any particular query. - - Since a verified NSEC RR proves the existence of both itself and its - corresponding RRSIG RR, a verifier MUST ignore the settings of the - NSEC and RRSIG bits in an NSEC RR. - -5.5 Authentication Example - - Appendix C shows an example the authentication process. - - - - - -Arends, et al. Expires August 16, 2004 [Page 33] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -6. IANA Considerations - - [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA - considerations introduced by DNSSEC. The additional IANA - considerations discussed in this document: - - [RFC2535] reserved the CD and AD bits in the message header. The - meaning of the AD bit was redefined in [RFC3655] and the meaning of - both the CD and AD bit are restated in this document. No new bits in - the DNS message header are defined in this document. - - [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit - and defined its use. The use is restated but not altered in this - document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 34] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -7. Security Considerations - - This document describes how the DNS security extensions use public - key cryptography to sign and authenticate DNS resource record sets. - Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general - security considerations related to DNSSEC; see - [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the - DNSSEC resource record types. - - An active attacker who can set the CD bit in a DNS query message or - the AD bit in a DNS response message can use these bits to defeat the - protection which DNSSEC attempts to provide to security-oblivious - recursive-mode resolvers. For this reason, use of these control bits - by a security-aware recursive-mode resolver requires a secure - channel. See Section 3.2.2 and Section 4.8 for further discussion. - - The protocol described in this document attempts to extend the - benefits of DNSSEC to security-oblivious stub resolvers. However, - since recovery from validation failures is likely to be specific to - particular applications, the facilities that DNSSEC provides for stub - resolvers may prove inadequate. Operators of security-aware - recursive name servers will need to pay close attention to the - behavior of the applications which use their services when choosing a - local validation policy; failure to do so could easily result in the - recursive name server accidently denying service to the clients it is - intended to support. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 35] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -8. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 36] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-09 (work in progress), - February 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-07 (work in progress), - February 2004. - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 37] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Informative References - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [I-D.ietf-dnsext-wcard-clarify] - Halley, B. and E. Lewis, "Clarifying the Role of Wild Card - Domains in the Domain Name System", - draft-ietf-dnsext-wcard-clarify-02 (work in progress), - September 2003. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - - - - -Arends, et al. Expires August 16, 2004 [Page 38] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 39] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Appendix A. Signed Zone Example - - The following example shows a (small) complete signed zone. - - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - 3600 NS ns1.example. - 3600 NS ns2.example. - 3600 RRSIG NS 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz - +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj - s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY - eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH - FTVyQbVkcaxQ6U2FbZtMbfo//go= ) - 3600 MX 1 xx.example. - 3600 RRSIG MX 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18 - 7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe - IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+ - M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q - 7wxkDWyzgasGiMNIKgYrm9vXz04= ) - 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - 3600 RRSIG NSEC 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT - vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX - TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g - Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 - 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) - 3600 DNSKEY 256 3 5 ( - AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH - UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV - fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv - BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO - - - -Arends, et al. Expires August 16, 2004 [Page 40] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - 5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q== - ) - 3600 DNSKEY 257 3 5 ( - AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U - Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv - klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE - 2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT - nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ== - ) - 3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU - pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5 - YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc - tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG - PjJstq6fvRq8kX7TPJcljUmDFKM= ) - 3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( - 20031216201552 60717 example. - EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/ - C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK - L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY - J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34 - Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= ) - a.example. 3600 IN NS ns1.a.example. - 3600 IN NS ns2.a.example. - 3600 DS 48327 5 1 ( - DFEB5E00E71A4DED5CABBBD7F15F24871983 - CAB7 ) - 3600 RRSIG DS 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ - hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb - rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c - ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC - 0yfe2uolEkeegjesDZuF+fC61Eg= ) - 3600 NSEC ai.example. NS DS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb - RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1 - 3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O - ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf - YgfAHJEJJj7K88QbKEK4/Je1hyk= ) - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - ai.example. 3600 IN A 192.0.2.9 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - - - -Arends, et al. Expires August 16, 2004 [Page 41] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 - jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c - Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk - OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A - sWifTxvcG5hv+A6TOd0O2xJYRik= ) - 3600 HINFO "KLH-10" "ITS" - 3600 RRSIG HINFO 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - 4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C - hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2 - KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2 - Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92 - xo9NLoltg0GuwggZM240pRoTwO8= ) - 3600 AAAA 2001:db8::f00:baa9 - 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 - 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ - G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI - A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI - zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) - 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE - ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y - ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU - 4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR - ovChG5Ih3TOa8Qnch4IJQVfSFNU= ) - b.example. 3600 IN NS ns1.b.example. - 3600 IN NS ns2.b.example. - 3600 NSEC ns1.example. NS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs - VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW - VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN - k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX - GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - ns1.example. 3600 IN A 192.0.2.1 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 - CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs - RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf - +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa - - - -Arends, et al. Expires August 16, 2004 [Page 42] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) - 3600 NSEC ns2.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ - sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 - eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA - s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj - I2A5W86mMEbSgEF/pZHX/wi5FJI= ) - ns2.example. 3600 IN A 192.0.2.2 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL - xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK - HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht - sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG - wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) - 3600 NSEC *.w.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb - IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b - f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J - aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl - yCup5bk/Dr47eU2/6+lqrBTOV8Q= ) - *.w.example. 3600 IN MX 1 ai.example. - 3600 RRSIG MX 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg - OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns - Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA - n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK - 91Ena87PA2MvoOE+A3ZpEk8MjEE= ) - 3600 NSEC x.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr - f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 - 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK - /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW - ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) - x.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 3 3600 20040115201552 ( - 20031216201552 41681 example. - g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW - ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m - 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY - MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv - - - -Arends, et al. Expires August 16, 2004 [Page 43] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - btznHMFDIbtuw/tAX7xXH2pDDHY= ) - 3600 NSEC x.y.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 3 3600 20040115201552 ( - 20031216201552 41681 example. - zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia - CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA - EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA - aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT - 3lMXiX4KNWUhB87q/pT/5z+xrqY= ) - x.y.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD - v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE - unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK - Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk - Iykd5UmaTO5j4LlRnAvF8Z1m9/k= ) - 3600 NSEC xx.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 - VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj - Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq - AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J - viOQHZ6I4xoZQP5G7r98/PhlrLM= ) - xx.example. 3600 IN A 192.0.2.10 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap - tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq - iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS - KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G - 0ToQVY81bPc3WXKZjRxQl3jiKtU= ) - 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw - p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA - gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/ - pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp - EDXT07qFXtGntvBSpF9uQbEub6Y= ) - 3600 AAAA 2001:db8::f00:baaa - 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 - dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD - mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg - CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z - - - -Arends, et al. Expires August 16, 2004 [Page 44] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - D4ZubIon0XGe9fIjLnmb3pX/FUk= ) - 3600 NSEC example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn - uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE - NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a - 1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187 - sSNF3PAC0HPadh7SdHmXlFQtQ44= ) - - The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA - Flags indicate that each of these DNSKEY RRs is a zone key. One of - these DNSKEY RRs also has the SEP flag set and has been used to sign - the apex DNSKEY RRset; this is the key which should be hashed to - generate a DS record to be inserted into the parent zone. The other - DNSKEY is used to sign all the other RRsets in the zone. - - The zone includes a wildcard entry "*.w.example". Note that the name - "*.w.example" is used in constructing NSEC chains, and that the RRSIG - covering the "*.w.example" MX RRset has a label count of 2. - - The zone also includes two delegations. The delegation to - "b.example" includes an NS RRset, glue address records, and an NSEC - RR; note that only the NSEC RRset is signed. The delegation to - "a.example" provides a DS RR; note that only the NSEC and DS RRsets - are signed. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 45] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Appendix B. Example Responses - - The examples in this section show response messages using the signed - zone example in Appendix A. - -B.1 Answer - - A successful query to an authoritative server. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - x.w.example. IN MX - - ;; Answer - x.w.example. 3600 IN MX 1 xx.example. - x.w.example. 3600 RRSIG MX 5 3 3600 20040115201552 ( - 20031216201552 41681 example. - g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW - ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m - 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY - MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv - btznHMFDIbtuw/tAX7xXH2pDDHY= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz - +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj - s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY - eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH - FTVyQbVkcaxQ6U2FbZtMbfo//go= ) - - ;; Additional - xx.example. 3600 IN A 192.0.2.10 - xx.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap - tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq - iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS - KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G - 0ToQVY81bPc3WXKZjRxQl3jiKtU= ) - xx.example. 3600 AAAA 2001:db8::f00:baaa - xx.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 - - - -Arends, et al. Expires August 16, 2004 [Page 46] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD - mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg - CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z - D4ZubIon0XGe9fIjLnmb3pX/FUk= ) - ns1.example. 3600 IN A 192.0.2.1 - ns1.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 - CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs - RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf - +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa - WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) - ns2.example. 3600 IN A 192.0.2.2 - ns2.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL - xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK - HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht - sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG - wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) - - -B.2 Name Error - - An authoritative name error. The NSEC RRs prove that the name does - not exist and that no covering wildcard exists. - - ;; Header: QR AA DO RCODE=3 - ;; - ;; Question - ml.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - - - -Arends, et al. Expires August 16, 2004 [Page 47] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs - VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW - VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN - k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX - GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT - vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX - TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g - Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 - 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) - - ;; Additional - ;; (empty) - - -B.3 No Data Error - - A "NODATA" response. The NSEC RR proves that the name exists and - that the requested RR type does not. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - ns1.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - - - -Arends, et al. Expires August 16, 2004 [Page 48] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC - ns1.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ - sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 - eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA - s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj - I2A5W86mMEbSgEF/pZHX/wi5FJI= ) - - ;; Additional - ;; (empty) - - -B.4 Referral to Signed Zone - - Referral to a signed zone. The DS RR contains the data which the - resolver will need to validate the corresponding DNSKEY RR in the - child zone's apex. - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.a.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - a.example. 3600 IN NS ns1.a.example. - a.example. 3600 IN NS ns2.a.example. - a.example. 3600 DS 48327 5 1 ( - DFEB5E00E71A4DED5CABBBD7F15F24871983 - CAB7 ) - a.example. 3600 RRSIG DS 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ - hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb - rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c - ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC - 0yfe2uolEkeegjesDZuF+fC61Eg= ) - - ;; Additional - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - - - - -Arends, et al. Expires August 16, 2004 [Page 49] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -B.5 Referral to Unsigned Zone - - Referral to an unsigned zone. The NSEC RR proves that no DS RR for - this delegation exists in the parent zone. - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.b.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - b.example. 3600 IN NS ns1.b.example. - b.example. 3600 IN NS ns2.b.example. - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs - VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW - VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN - k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX - GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) - - ;; Additional - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - - -B.6 Wildcard Expansion - - A successful query which was answered via wildcard expansion. The - label count in the answer's RRSIG RR indicates that a wildcard RRset - was expanded to produce this response, and the NSEC RR proves that no - closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN MX - - ;; Answer - a.z.w.example. 3600 IN MX 1 ai.example. - a.z.w.example. 3600 RRSIG MX 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg - OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns - - - -Arends, et al. Expires August 16, 2004 [Page 50] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA - n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK - 91Ena87PA2MvoOE+A3ZpEk8MjEE= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz - +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj - s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY - eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH - FTVyQbVkcaxQ6U2FbZtMbfo//go= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 - VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj - Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq - AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J - viOQHZ6I4xoZQP5G7r98/PhlrLM= ) - - ;; Additional - ai.example. 3600 IN A 192.0.2.9 - ai.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 - jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c - Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk - OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A - sWifTxvcG5hv+A6TOd0O2xJYRik= ) - ai.example. 3600 AAAA 2001:db8::f00:baa9 - ai.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 - 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ - G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI - A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI - zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) - - -B.7 Wildcard No Data Error - - A "NODATA" response for a name covered by a wildcard. The NSEC RRs - prove that the matching wildcard name does not have any RRs of the - requested type and that no closer match exists in the zone. - - - - -Arends, et al. Expires August 16, 2004 [Page 51] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 - VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj - Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq - AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J - viOQHZ6I4xoZQP5G7r98/PhlrLM= ) - *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC - *.w.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr - f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 - 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK - /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW - ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) - - ;; Additional - ;; (empty) - - -B.8 DS Child Zone No Data Error - - A "NODATA" response for a QTYPE=DS query which was mistakenly sent to - a name server for the child zone. - - - -Arends, et al. Expires August 16, 2004 [Page 52] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - example. IN DS - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT - vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX - TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g - Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 - 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) - - ;; Additional - ;; (empty) - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 53] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Appendix C. Authentication Examples - - The examples in this section show how the response messages in - Appendix B are authenticated. - -C.1 Authenticating An Answer - - The query in section Appendix B.1 returned an MX RRset for - "x.w.example.com". The corresponding RRSIG indicates the MX RRset was - signed by an "example" DNSKEY with algorithm 5 and key tag 41681. - The resolver needs the corresponding DNSKEY RR in order to - authenticate this answer. The discussion below describes how a - resolver might obtain this DNSKEY RR. - - The RRSIG indicates the original TTL of the MX RRset was 3600 and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 3 indicates the answer was - not the result of wildcard expansion. The "x.w.example.com" MX RRset - is placed in canonical form and, assuming the current time falls - between the signature inception and expiration dates, the signature - is authenticated. - -C.1.1 Authenticating the example DNSKEY RR - - This example shows the logical authentication process that starts - from the a preconfigured root DNSKEY (or DS RR) and moves down the - tree to authenticate the desired "example" DNSKEY RR. Note the - logical order is presented for clarity and an implementation may - choose to construct the authentication as referrals are received or - may choose to construct the authentication chain only after all - RRsets have been obtained, or in any other combination it sees fit. - The example here demonstrates only the logical process and does not - dictate any implementation rules. - - We assume the resolver starts with an preconfigured DNSKEY RR for the - root zone (or a preconfigured DS RR for the root zone). The resolver - checks this preconfigured DNSKEY RR is present in the root DNSKEY - RRset (or the DS RR matches some DNSKEY in the root DNSKEY RRset), - this DNSKEY RR has signed the root DNSKEY RRset and the signature - lifetime is valid. If all these conditions are met, all keys in the - DNSKEY RRset are considered authenticated. The resolver then uses - one (or more) of the root DNSKEY RRs to authenticate the "example" DS - RRset. Note the resolver may need to query the root zone to obtain - the root DNSKEY RRset and/or "example" DS RRset. - - Once the DS RRset has been authenticated using the root DNSKEY, the - resolver checks the "example" DNSKEY RRset for some "example" DNSKEY - RR that matches one of the authenticated "example" DS RRs. If such a - - - -Arends, et al. Expires August 16, 2004 [Page 54] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - matching "example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the "example" - DNSKEY RRset are considered authenticated. - - Finally the resolver checks that some DNSKEY RR in the "example" - DNSKEY RRset uses algorithm 5 and has a key tag of 41681. This - DNSKEY is used to authenticated the RRSIG included in the response. - If multiple "example" DNSKEY RRs have algorithm 5 and key tag of - 41681, then each DNSKEY RR is tried and the answer is authenticated - if either DNSKEY RR validates the signature as described above. - -C.2 Name Error - - The query in section Appendix B.2 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. The NSEC RRs are - authenticated in a manner identical to that of the MX RRset discussed - above. - -C.3 No Data Error - - The query in section Appendix B.3 returned an NSEC RR that proves the - requested name exists, but the requested RR type does not exist. The - negative reply is authenticated by verifying the NSEC RR. The NSEC - RR is authenticated in a manner identical to that of the MX RRset - discussed above. - -C.4 Referral to Signed Zone - - The query in section Appendix B.4 returned a referral to the signed - "a.example." zone. The DS RR is authenticated in a manner identical - to that of the MX RRset discussed above. This DS RR is used to - authenticate the "a.example" DNSKEY RRset. - - Once the "a.example" DS RRset has been authenticated using the - "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset - for some "a.example" DNSKEY RR that matches the DS RR. If such a - matching "a.example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "a.example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the - "a.example" DNSKEY RRset are considered authenticated. - -C.5 Referral to Unsigned Zone - - The query in section Appendix B.5 returned a referral to an unsigned - "b.example." zone. The NSEC proves that no authentication leads from - "example" to "b.example" and the NSEC RR is authenticated in a manner - - - -Arends, et al. Expires August 16, 2004 [Page 55] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - identical to that of the MX RRset discussed above. - -C.6 Wildcard Expansion - - The query in section Appendix B.6 returned an answer that was - produced as a result of wildcard expansion. The RRset expanded as - the similar to The corresponding RRSIG indicates the MX RRset was - signed by an "example" DNSKEY with algorithm 5 and key tag 41681. - The RRSIG indicates the original TTL of the MX RRset was 3600 and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 2 indicates the answer the - result of wildcard expansion since the "a.z.w.example" name contains - 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", - the MX RRset is placed in canonical form and, assuming the current - time falls between the signature inception and expiration dates, the - signature is authenticated. - - The NSEC proves that no closer match (exact or closer wildcard) could - have been used to answer this query and the NSEC RR must also be - authenticated before the answer is considered valid. - -C.7 Wildcard No Data Error - - The query in section Appendix B.7 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. - -C.8 DS Child Zone No Data Error - - The query in section Appendix B.8 returned NSEC RRs that shows the - requested was answered by a child server ("example" server). The - NSEC RR indicates the presence of an SOA RR, showing the answer is - from the child . Queries for the "example" DS RRset should be sent - to the parent servers ("root" servers). - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 56] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires August 16, 2004 [Page 57] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 58] - - +
+
+DNS Extensions R. Arends
+Internet-Draft Telematica Instituut
+Expires: November 15, 2004 M. Larson
+ VeriSign
+ R. Austein
+ ISC
+ D. Massey
+ USC/ISI
+ S. Rose
+ NIST
+ May 17, 2004
+
+
+ Protocol Modifications for the DNS Security Extensions
+ draft-ietf-dnsext-dnssec-protocol-06
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on November 15, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document is part of a family of documents which describe the DNS
+ Security Extensions (DNSSEC). The DNS Security Extensions are a
+ collection of new resource records and protocol modifications which
+ add data origin authentication and data integrity to the DNS. This
+ document describes the DNSSEC protocol modifications. This document
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 1]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ defines the concept of a signed zone, along with the requirements for
+ serving and resolving using DNSSEC. These techniques allow a
+ security-aware resolver to authenticate both DNS resource records and
+ authoritative DNS error indications.
+
+ This document obsoletes RFC 2535 and incorporates changes from all
+ updates to RFC 2535.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1 Background and Related Documents . . . . . . . . . . . . . 4
+ 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . 4
+ 1.3.2 Technical Changes or Corrections . . . . . . . . . . . 4
+ 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . 5
+ 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 6
+ 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 6
+ 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 7
+ 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 8
+ 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 8
+ 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . 9
+ 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 11
+ 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 11
+ 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 12
+ 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 12
+ 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 15
+ 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 16
+ 3.1.6 The AD and CD Bits in an Authoritative Response . . . 17
+ 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17
+ 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 18
+ 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 18
+ 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 19
+ 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 19
+ 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 20
+ 4.2 Signature Verification Support . . . . . . . . . . . . . . 20
+ 4.3 Determining Security Status of Data . . . . . . . . . . . 21
+ 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 21
+ 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22
+ 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22
+ 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22
+ 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23
+ 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23
+ 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 24
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 2]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 24
+ 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24
+ 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
+ 5.1 Special Considerations for Islands of Security . . . . . . 26
+ 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26
+ 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27
+ 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28
+ 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28
+ 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30
+ 5.3.4 Authenticating A Wildcard Expanded RRset Positive
+ Response . . . . . . . . . . . . . . . . . . . . . . . 31
+ 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31
+ 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32
+ 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
+ 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
+ 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
+ A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39
+ B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45
+ B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45
+ B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46
+ B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47
+ B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48
+ B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49
+ B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50
+ B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51
+ B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52
+ C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54
+ C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54
+ C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54
+ C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55
+ C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55
+ C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55
+ C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55
+ C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56
+ C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56
+ C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56
+ Intellectual Property and Copyright Statements . . . . . . . . 57
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 3]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+1. Introduction
+
+ The DNS Security Extensions (DNSSEC) are a collection of new resource
+ records and protocol modifications which add data origin
+ authentication and data integrity to the DNS. This document defines
+ the DNSSEC protocol modifications. Section 2 of this document defines
+ the concept of a signed zone and lists the requirements for zone
+ signing. Section 3 describes the modifications to authoritative name
+ server behavior necessary to handle signed zones. Section 4 describes
+ the behavior of entities which include security-aware resolver
+ functions. Finally, Section 5 defines how to use DNSSEC RRs to
+ authenticate a response.
+
+1.1 Background and Related Documents
+
+ The reader is assumed to be familiar with the basic DNS concepts
+ described in [RFC1034] and [RFC1035].
+
+ This document is part of a family of documents that define DNSSEC.
+ An introduction to DNSSEC and definition of common terms can be found
+ in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC
+ resource records can be found in [I-D.ietf-dnsext-dnssec-records].
+
+1.2 Reserved Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119. [RFC2119].
+
+1.3 Editors' Notes
+
+1.3.1 Open Technical Issues
+
+1.3.2 Technical Changes or Corrections
+
+ Please report technical corrections to dnssec-editors@east.isi.edu.
+ To assist the editors, please indicate the text in error and point
+ out the RFC that defines the correct behavior. For a technical
+ change where no RFC that defines the correct behavior, or if there's
+ more than one applicable RFC and the definitions conflict, please
+ post the issue to namedroppers.
+
+ An example correction to dnssec-editors might be: Page X says
+ "DNSSEC RRs SHOULD be automatically returned in responses." This was
+ true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
+ DNSSEC RR types MUST NOT be included in responses unless the resolver
+ indicated support for DNSSEC.
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 4]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+1.3.3 Typos and Minor Corrections
+
+ Please report any typos corrections to dnssec-editors@east.isi.edu.
+ To assist the editors, please provide enough context for us to find
+ the incorrect text quickly.
+
+ An example message to dnssec-editors might be: page X says "the
+ DNSSEC standard has been in development for over 1 years". It
+ should read "over 10 years".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 5]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+2. Zone Signing
+
+ DNSSEC introduces the concept of signed zones. A signed zone
+ includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
+ the rules specified in Section 2.1, Section 2.2, Section 2.3 and
+ Section 2.4, respectively. A zone that does not include these
+ records according to the rules in this section is an unsigned zone.
+
+ DNSSEC requires a change to the definition of the CNAME resource
+ record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG
+ and NSEC RRs to appear at the same owner name as a CNAME RR.
+
+2.1 Including DNSKEY RRs in a Zone
+
+ To sign a zone, the zone's administrator generates one or more
+ public/private key pairs and uses the private key(s) to sign
+ authoritative RRsets in the zone. For each private key used to
+ create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with
+ the public component stored in the zone. A zone key DNSKEY RR MUST
+ have the Zone Key bit of the flags RDATA field set to one -- see
+ Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys
+ associated with other DNS operations MAY be stored in DNSKEY RRs that
+ are not marked as zone keys but MUST NOT be used to verify RRSIGs.
+
+ If the zone is delegated and does not wish to act as an island of
+ security, the zone MUST have at least one DNSKEY RR at the apex to
+ act as a secure entry point into the zone. This DNSKEY would then be
+ used to generate a DS RR at the delegating parent (see
+ [I-D.ietf-dnsext-dnssec-records]).
+
+ DNSKEY RRs MUST NOT appear at delegation points.
+
+2.2 Including RRSIG RRs in a Zone
+
+ For each authoritative RRset in a signed zone, there MUST be at least
+ one RRSIG record that meets all of the following requirements:
+ o The RRSIG owner name is equal to the RRset owner name;
+ o The RRSIG class is equal to the RRset class;
+ o The RRSIG Type Covered field is equal to the RRset type;
+ o The RRSIG Original TTL field is equal to the TTL of the RRset;
+ o The RRSIG RR's TTL is equal to the TTL of the RRset;
+ o The RRSIG Labels field is equal to the number of labels in the
+ RRset owner name, not counting the null root label and not
+ counting the leftmost label if it is a wildcard;
+ o The RRSIG Signer's Name field is equal to the name of the zone
+ containing the RRset; and
+ o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
+ zone key DNSKEY record at the zone apex.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 6]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ The process for constructing the RRSIG RR for a given RRset is
+ described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
+ multiple RRSIG RRs associated with it.
+
+ An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
+ would add no value and would create an infinite loop in the signing
+ process.
+
+ The NS RRset that appears at the zone apex name MUST be signed, but
+ the NS RRsets that appear at delegation points (that is, the NS
+ RRsets in the parent zone that delegate the name to the child zone's
+ name servers) MUST NOT be signed. Glue address RRsets associated with
+ delegations MUST NOT be signed.
+
+ There MUST be an RRSIG for each RRset using at least one DNSKEY of
+ each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
+ itself MUST be signed by each algorithm appearing in the DS RRset
+ located at the delegating parent (if any).
+
+2.3 Including NSEC RRs in a Zone
+
+ Each owner name in the zone which has authoritative data or a
+ delegation point NS RRset MUST have an NSEC resource record. The
+ process for constructing the NSEC RR for a given name is described in
+ [I-D.ietf-dnsext-dnssec-records].
+
+ The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
+ value field in the zone SOA RR.
+
+ An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
+ RRset at any particular owner name. That is, the signing process
+ MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
+ not the owner name of any RRset before the zone was signed. The main
+ reasons for this are a desire for namespace consistency between
+ signed and unsigned versions of the same zone and a desire to reduce
+ the risk of response inconsistency in security oblivious recursive
+ name servers.
+
+ The type bitmap of every NSEC resource record in a signed zone MUST
+ indicate the presence of both the NSEC record itself and its
+ corresponding RRSIG record.
+
+ The difference between the set of owner names that require RRSIG
+ records and the set of owner names that require NSEC records is
+ subtle and worth highlighting. RRSIG records are present at the
+ owner names of all authoritative RRsets. NSEC records are present at
+ the owner names of all names for which the signed zone is
+ authoritative and also at the owner names of delegations from the
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 7]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ signed zone to its children. Neither NSEC nor RRSIG records are
+ present (in the parent zone) at the owner names of glue address
+ RRsets. Note, however, that this distinction is for the most part is
+ only visible during the zone signing process, because NSEC RRsets are
+ authoritative data, and are therefore signed, thus any owner name
+ which has an NSEC RRset will have RRSIG RRs as well in the signed
+ zone.
+
+ The bitmap for the NSEC RR at a delegation point requires special
+ attention. Bits corresponding to the delegation NS RRset and the RR
+ types for which the parent zone has authoritative data MUST be set to
+ 1; bits corresponding to any non-NS RRset for which the parent is not
+ authoritative MUST be set to 0.
+
+2.4 Including DS RRs in a Zone
+
+ The DS resource record establishes authentication chains between DNS
+ zones. A DS RRset SHOULD be present at a delegation point when the
+ child zone is signed. The DS RRset MAY contain multiple records,
+ each referencing a public key in the child zone used to verify the
+ RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS
+ RRsets MUST NOT appear at a zone's apex.
+
+ A DS RR SHOULD point to a DNSKEY RR which is present in the child's
+ apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
+ by the corresponding private key.
+
+ The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
+ (i.e., the NS RRset from the same zone containing the DS RRset).
+
+ Construction of a DS RR requires knowledge of the corresponding
+ DNSKEY RR in the child zone, which implies communication between the
+ child and parent zones. This communication is an operational matter
+ not covered by this document.
+
+2.5 Changes to the CNAME Resource Record.
+
+ If a CNAME RRset is present at a name in a signed zone, appropriate
+ RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
+ name for secure dynamic update purposes is also allowed. Other types
+ MUST NOT be present at that name.
+
+ This is a modification to the original CNAME definition given in
+ [RFC1034]. The original definition of the CNAME RR did not allow any
+ other types to coexist with a CNAME record, but a signed zone
+ requires NSEC and RRSIG RRs for every authoritative name. To resolve
+ this conflict, this specification modifies the definition of the
+ CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 8]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+2.6 Example of a Secure Zone
+
+ Appendix A shows a complete example of a small signed zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 9]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+3. Serving
+
+ This section describes the behavior of entities that include
+ security-aware name server functions. In many cases such functions
+ will be part of a security-aware recursive name server, but a
+ security-aware authoritative name server has some of the same
+ requirements. Functions specific to security-aware recursive name
+ servers are described in Section 3.2; functions specific to
+ authoritative servers are described in Section 3.1.
+
+ The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
+ are as used in [RFC1034].
+
+ A security-aware name server MUST support the EDNS0 [RFC2671] message
+ size extension, MUST support a message size of at least 1220 octets,
+ and SHOULD support a message size of 4000 octets [RFC3226].
+
+ A security-aware name server that receives a DNS query that does not
+ include the EDNS OPT pseudo-RR or that has the DO bit set to zero
+ MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
+ RRset, and MUST NOT perform any of the additional processing
+ described below. Since the DS RR type has the peculiar property of
+ only existing in the parent zone at delegation points, DS RRs always
+ require some special processing, as described in Section 3.1.4.1.
+
+ Security aware name servers that receive queries for security RR
+ types which match the content of more than one zone that it serves
+ (e.g. NSEC and RRSIG RRs above and below a delegation point where the
+ server is authoritative for both zones) are encouraged to behave
+ self-consistently. The name server MAY return one of the following:
+ o The above-delegation RRsets
+ o The below-delegation RRsets
+ o Both above and below-delegation RRsets
+ o Empty answer section (i.e. no records)
+ o Some other response
+ o An error
+ As long as the response is always consistent for each query to the
+ name server.
+
+ DNSSEC allocates two new bits in the DNS message header: the CD
+ (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit
+ is controlled by resolvers; a security-aware name server MUST copy
+ the CD bit from a query into the corresponding response. The AD bit
+ is controlled by name servers; a security-aware name server MUST
+ ignore the setting of the AD bit in queries. See Section 3.1.6,
+ Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details
+ on the behavior of these bits.
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 10]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ A security aware name server which synthesizes CNAME RRs from DNAME
+ RRs as described in [RFC2672] SHOULD NOT generate signatures for the
+ synthesized CNAME RRs.
+
+3.1 Authoritative Name Servers
+
+ Upon receiving a relevant query that has the EDNS [RFC2671] OPT
+ pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative
+ name server for a signed zone MUST include additional RRSIG, NSEC,
+ and DS RRs according to the following rules:
+ o RRSIG RRs that can be used to authenticate a response MUST be
+ included in the response according to the rules in Section 3.1.1;
+ o NSEC RRs that can be used to provide authenticated denial of
+ existence MUST be included in the response automatically according
+ to the rules in Section 3.1.3;
+ o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
+ be included in referrals automatically according to the rules in
+ Section 3.1.4.
+
+ DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
+ discusses zone transfer requirements.
+
+3.1.1 Including RRSIG RRs in a Response
+
+ When responding to a query that has the DO bit set to one, a
+ security-aware authoritative name server SHOULD attempt to send RRSIG
+ RRs that a security-aware resolver can use to authenticate the RRsets
+ in the response. A name server SHOULD make every attempt to keep the
+ RRset and its associated RRSIG(s) together in a response. Inclusion
+ of RRSIG RRs in a response is subject to the following rules:
+ o When placing a signed RRset in the Answer section, the name server
+ MUST also place its RRSIG RRs in the Answer section. The RRSIG
+ RRs have a higher priority for inclusion than any other RRsets
+ that may need to be included. If space does not permit inclusion
+ of these RRSIG RRs, the name server MUST set the TC bit.
+ o When placing a signed RRset in the Authority section, the name
+ server MUST also place its RRSIG RRs in the Authority section.
+ The RRSIG RRs have a higher priority for inclusion than any other
+ RRsets that may need to be included. If space does not permit
+ inclusion of these RRSIG RRs, the name server MUST set the TC bit.
+ o When placing a signed RRset in the Additional section, the name
+ server MUST also place its RRSIG RRs in the Additional section.
+ If space does not permit inclusion of both the RRset and its
+ associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If
+ this happens, the name server MUST NOT set the TC bit solely
+ because these RRSIG RRs didn't fit.
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 11]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+3.1.2 Including DNSKEY RRs In a Response
+
+ When responding to a query that has the DO bit set to one and that
+ requests the SOA or NS RRs at the apex of a signed zone, a
+ security-aware authoritative name server for that zone MAY return the
+ zone apex DNSKEY RRset in the Additional section. In this situation,
+ the DNSKEY RRset and associated RRSIG RRs have lower priority than
+ any other information that would be placed in the additional section.
+ The name server SHOULD NOT include the DNSKEY RRset unless there is
+ enough space in the response message for both the DNSKEY RRset and
+ its associated RRSIG RR(s). If there is not enough space to include
+ these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
+ NOT set the TC bit solely because these RRs didn't fit (see Section
+ 3.1.1).
+
+3.1.3 Including NSEC RRs In a Response
+
+ When responding to a query that has the DO bit set to one, a
+ security-aware authoritative name server for a signed zone MUST
+ include NSEC RRs in each of the following cases:
+
+ No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
+ but does not contain any RRsets that exactly match <SNAME, SCLASS,
+ STYPE>.
+
+ Name Error: The zone does not contain any RRsets that match <SNAME,
+ SCLASS> either exactly or via wildcard name expansion.
+
+ Wildcard Answer: The zone does not contain any RRsets that exactly
+ match <SNAME, SCLASS> but does contain an RRset that matches
+ <SNAME, SCLASS, STYPE> via wildcard name expansion.
+
+ Wildcard No Data: The zone does not contain any RRsets that exactly
+ match <SNAME, SCLASS>, does contain one or more RRsets that match
+ <SNAME, SCLASS> via wildcard name expansion, but does not contain
+ any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name
+ expansion.
+
+ In each of these cases, the name server includes NSEC RRs in the
+ response to prove that an exact match for <SNAME, SCLASS, STYPE> was
+ not present in the zone and that the response that the name server is
+ returning is correct given the data that are in the zone.
+
+3.1.3.1 Including NSEC RRs: No Data Response
+
+ If the zone contains RRsets matching <SNAME, SCLASS> but contains no
+ RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
+ include the NSEC RR for <SNAME, SCLASS> along with its associated
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 12]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ RRSIG RR(s) in the Authority section of the response (see Section
+ 3.1.1). If space does not permit inclusion of the NSEC RR or its
+ associated RRSIG RR(s), the name server MUST set the TC bit (see
+ Section 3.1.1).
+
+ Since the search name exists, wildcard name expansion does not apply
+ to this query, and a single signed NSEC RR suffices to prove the
+ requested RR type does not exist.
+
+3.1.3.2 Including NSEC RRs: Name Error Response
+
+ If the zone does not contain any RRsets matching <SNAME, SCLASS>
+ either exactly or via wildcard name expansion, then the name server
+ MUST include the following NSEC RRs in the Authority section, along
+ with their associated RRSIG RRs:
+ o An NSEC RR proving that there is no exact match for <SNAME,
+ SCLASS>; and
+ o An NSEC RR proving that the zone contains no RRsets that would
+ match <SNAME, SCLASS> via wildcard name expansion.
+
+ In some cases a single NSEC RR may prove both of these points, in
+ that case the name server SHOULD only include the NSEC RR and its
+ RRSIG RR(s) once in the Authority section.
+
+ If space does not permit inclusion of these NSEC and RRSIG RRs, the
+ name server MUST set the TC bit (see Section 3.1.1).
+
+ The owner names of these NSEC and RRSIG RRs are not subject to
+ wildcard name expansion when these RRs are included in the Authority
+ section of the response.
+
+ Note that this form of response includes cases in which SNAME
+ corresponds to an empty non-terminal name within the zone (a name
+ which is not the owner name for any RRset but which is the parent
+ name of one or more RRsets).
+
+3.1.3.3 Including NSEC RRs: Wildcard Answer Response
+
+ If the zone does not contain any RRsets which exactly match <SNAME,
+ SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
+ STYPE> via wildcard name expansion, the name server MUST include the
+ wildcard-expanded answer and the corresponding wildcard-expanded
+ RRSIG RRs in the Answer section, and MUST include in the Authority
+ section an NSEC RR and associated RRSIG RR(s) proving that the zone
+ does not contain a closer match for <SNAME, SCLASS>. If space does
+ not permit inclusion of the answer, NSEC and RRSIG RRs, the name
+ server MUST set the TC bit (see Section 3.1.1).
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 13]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+3.1.3.4 Including NSEC RRs: Wildcard No Data Response
+
+ This case is a combination of the previous cases. The zone does not
+ contain an exact match for <SNAME, SCLASS>, and while the zone does
+ contain RRsets which match <SNAME, SCLASS> via wildcard expansion,
+ none of those RRsets match STYPE. The name server MUST include the
+ following NSEC RRs in the Authority section, along with their
+ associated RRSIG RRs:
+ o An NSEC RR proving that there are no RRsets matching STYPE at the
+ wildcard owner name which matched <SNAME, SCLASS> via wildcard
+ expansion; and
+ o An NSEC RR proving that there are no RRsets in the zone which
+ would have been a closer match for <SNAME, SCLASS>.
+
+ In some cases a single NSEC RR may prove both of these points, in
+ which case the name server SHOULD only include the NSEC RR and its
+ RRSIG RR(s) once in the Authority section.
+
+ The owner names of these NSEC and RRSIG RRs are not subject to
+ wildcard name expansion when these RRs are included in the Authority
+ section of the response.
+
+ If space does not permit inclusion of these NSEC and RRSIG RRs, the
+ name server MUST set the TC bit (see Section 3.1.1).
+
+3.1.3.5 Finding The Right NSEC RRs
+
+ As explained above, there are several situations in which a
+ security-aware authoritative name server needs to locate an NSEC RR
+ which proves that no RRsets matching a particular SNAME exist.
+ Locating such an NSEC RR within an authoritative zone is relatively
+ simple, at least in concept. The following discussion assumes that
+ the name server is authoritative for the zone which would have held
+ the nonexistent RRsets matching SNAME. The algorithm below is
+ written for clarity, not efficiency.
+
+ To find the NSEC which proves that no RRsets matching name N exist in
+ the zone Z which would have held them, construct sequence S
+ consisting of the owner names of every RRset in Z, sorted into
+ canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate
+ names. Find the name M which would have immediately preceded N in S
+ if any RRsets with owner name N had existed. M is the owner name of
+ the NSEC RR which proves that no RRsets exist with owner name N.
+
+ The algorithm for finding the NSEC RR which proves that a given name
+ is not covered by any applicable wildcard is similar, but requires an
+ extra step. More precisely, the algorithm for finding the NSEC
+ proving that no RRsets exist with the applicable wildcard name is
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 14]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ precisely the same as the algorithm for finding the NSEC RR which
+ proves that RRsets with any other owner name do not exist: the part
+ that's missing is how to determine the name of the nonexistent
+ applicable wildcard. In practice, this is easy, because the
+ authoritative name server has already checked for the presence of
+ precisely this wildcard name as part of step (1)(c) of the normal
+ lookup algorithm described in Section 4.3.2 of [RFC1034].
+
+3.1.4 Including DS RRs In a Response
+
+ When responding to a query which has the DO bit set to one, a
+ security-aware authoritative name server returning a referral
+ includes DNSSEC data along with the NS RRset.
+
+ If a DS RRset is present at the delegation point, the name server
+ MUST return both the DS RRset and its associated RRSIG RR(s) in the
+ Authority section along with the NS RRset. The name server MUST
+ place the NS RRset before the DS RRset and its associated RRSIG
+ RR(s).
+
+ If no DS RRset is present at the delegation point, the name server
+ MUST return both the NSEC RR which proves that the DS RRset is not
+ present and the NSEC RR's associated RRSIG RR(s) along with the NS
+ RRset. The name server MUST place the NS RRset before the NSEC RRset
+ and its associated RRSIG RR(s).
+
+ Including these DS, NSEC, and RRSIG RRs increases the size of
+ referral messages, and may cause some or all glue RRs to be omitted.
+ If space does not permit inclusion of the DS or NSEC RRset and
+ associated RRSIG RRs, the name server MUST set the TC bit (see
+ Section 3.1.1).
+
+3.1.4.1 Responding to Queries for DS RRs
+
+ The DS resource record type is unusual in that it appears only on the
+ parent zone's side of a zone cut. For example, the DS RRset for the
+ delegation of "foo.example" is stored in the "example" zone rather
+ than in the "foo.example" zone. This requires special processing
+ rules for both name servers and resolvers, since the name server for
+ the child zone is authoritative for the name at the zone cut by the
+ normal DNS rules but the child zone does not contain the DS RRset.
+
+ A security-aware resolver sends queries to the parent zone when
+ looking for a needed DS RR at a delegation point (see Section 4.2).
+ However, special rules are necessary to avoid confusing
+ security-oblivious resolvers which might become involved in
+ processing such a query (for example, in a network configuration that
+ forces a security-aware resolver to channel its queries through a
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 15]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ security-oblivious recursive name server). The rest of this section
+ describes how a security-aware name server processes DS queries in
+ order to avoid this problem.
+
+ The need for special processing by a security-aware name server only
+ arises when all the following conditions are met:
+ o the name server has received a query for the DS RRset at a zone
+ cut; and
+ o the name server is authoritative for the child zone; and
+ o the name server is not authoritative for the parent zone; and
+ o the name server does not offer recursion.
+
+ In all other cases, the name server either has some way of obtaining
+ the DS RRset or could not have been expected to have the DS RRset
+ even by the pre-DNSSEC processing rules, so the name server can
+ return either the DS RRset or an error response according to the
+ normal processing rules.
+
+ If all of the above conditions are met, however, the name server is
+ authoritative for SNAME but cannot supply the requested RRset. In
+ this case, the name server MUST return an authoritative "no data"
+ response showing that the DS RRset does not exist in the child zone's
+ apex. See Appendix B.8 for an example of such a response.
+
+3.1.5 Responding to Queries for Type AXFR or IXFR
+
+ DNSSEC does not change the DNS zone transfer process. A signed zone
+ will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
+ records have no special meaning with respect to a zone transfer
+ operation.
+
+ An authoritative name server is not required to verify that a zone is
+ properly signed before sending or accepting a zone transfer.
+ However, an authoritative name server MAY choose to reject the entire
+ zone transfer if the zone fails meets any of the signing requirements
+ described in Section 2. The primary objective of a zone transfer is
+ to ensure that all authoritative name servers have identical copies
+ of the zone. An authoritative name server that chooses to perform
+ its own zone validation MUST NOT selectively reject some RRs and
+ accept others.
+
+ DS RRsets appear only on the parental side of a zone cut and are
+ authoritative data in the parent zone. As with any other
+ authoritative RRset, the DS RRset MUST be included in zone transfers
+ of the zone in which the RRset is authoritative data: in the case of
+ the DS RRset, this is the parent zone.
+
+ NSEC RRs appear in both the parent and child zones at a zone cut, and
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 16]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ are authoritative data in both the parent and child zones. The
+ parental and child NSEC RRs at a zone cut are never identical to each
+ other, since the NSEC RR in the child zone's apex will always
+ indicate the presence of the child zone's SOA RR while the parental
+ NSEC RR at the zone cut will never indicate the presence of an SOA
+ RR. As with any other authoritative RRs, NSEC RRs MUST be included
+ in zone transfers of the zone in which they are authoritative data:
+ the parental NSEC RR at a zone cut MUST be included zone transfers of
+ the parent zone, while the NSEC at the zone apex of the child zone
+ MUST be included in zone transfers of the child zone.
+
+ RRSIG RRs appear in both the parent and child zones at a zone cut,
+ and are authoritative in whichever zone contains the authoritative
+ RRset for which the RRSIG RR provides the signature. That is, the
+ RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
+ authoritative in the parent zone, while the RRSIG for any RRset in
+ the child zone's apex will be authoritative in the child zone. As
+ with any other authoritative RRs, RRSIG RRs MUST be included in zone
+ transfers of the zone in which they are authoritative data.
+
+3.1.6 The AD and CD Bits in an Authoritative Response
+
+ The CD and AD bits are designed for use in communication between
+ security-aware resolvers and security-aware recursive name servers.
+ These bits are for the most part not relevant to query processing by
+ security-aware authoritative name servers.
+
+ A security-aware name server does not perform signature validation
+ for authoritative data during query processing even when the CD bit
+ is set to zero. A security-aware name server SHOULD clear the CD bit
+ when composing an authoritative response.
+
+ A security-aware name server MUST NOT set the AD bit in a response
+ unless the name server considers all RRsets in the Answer and
+ Authority sections of the response to be authentic. A security-aware
+ name server's local policy MAY consider data from an authoritative
+ zone to be authentic without further validation, but the name server
+ MUST NOT do so unless the name server obtained the authoritative zone
+ via secure means (such as a secure zone transfer mechanism), and MUST
+ NOT do so unless this behavior has been configured explicitly.
+
+ A security-aware name server which supports recursion MUST follow the
+ rules for the CD and AD bits given in Section 3.2 when generating a
+ response that involves data obtained via recursion.
+
+3.2 Recursive Name Servers
+
+ As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 17]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ recursive name server is an entity which acts in both the
+ security-aware name server and security-aware resolver roles. This
+ section uses the terms "name server side" and "resolver side" to
+ refer to the code within a security-aware recursive name server which
+ implements the security-aware name server role and the code which
+ implements the security-aware resolver role, respectively.
+
+ The resolver side follows the usual rules for caching and negative
+ caching which would apply to any security-aware resolver.
+
+3.2.1 The DO bit
+
+ The resolver side of a security-aware recursive name server MUST set
+ the DO bit when sending requests, regardless of the state of the DO
+ bit in the initiating request received by the name server side. If
+ the DO bit in an initiating query is not set, the name server side
+ MUST strip any authenticating DNSSEC RRs from the response, but MUST
+ NOT strip any DNSSEC RR types that the initiating query explicitly
+ requested.
+
+3.2.2 The CD bit
+
+ The CD bit exists in order to allow a security-aware resolver to
+ disable signature validation in a security-aware name server's
+ processing of a particular query.
+
+ The name server side MUST copy the setting of the CD bit from a query
+ to the corresponding response.
+
+ The name server side of a security-aware recursive name server MUST
+ pass the sense of the CD bit to the resolver side along with the rest
+ of an initiating query, so that the resolver side will know whether
+ or not it is required to verify the response data it returns to the
+ name server side. If the CD bit is set to one, it indicates that the
+ originating resolver is willing to perform whatever authentication
+ its local policy requires, thus the resolver side of the recursive
+ name server need not perform authentication on the RRsets in the
+ response. When the CD bit is set to one the recursive name server
+ SHOULD, if possible, return the requested data to the originating
+ resolver even if the recursive name server's local authentication
+ policy would reject the records in question. That is, by setting the
+ CD bit, the originating resolver has indicated that it takes
+ responsibility for performing its own authentication, and the
+ recursive name server should not interfere.
+
+ If the resolver side implements a BAD cache (see Section 4.7) and the
+ name server side receives a query which matches an entry in the
+ resolver side's BAD cache, the name server side's response depends on
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 18]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ the sense of the CD bit in the original query. If the CD bit is set,
+ the name server side SHOULD return the data from the BAD cache; if
+ the CD bit is not set, the name server side MUST return RCODE 2
+ (server failure).
+
+ The intent of the above rule is to provide the raw data to clients
+ which are capable of performing their own signature verification
+ checks while protecting clients which depend on the resolver side of
+ a security-aware recursive name server to perform such checks.
+ Several of the possible reasons why signature validation might fail
+ involve conditions which may not apply equally to the recursive name
+ server and the client which invoked it: for example, the recursive
+ name server's clock may be set incorrectly, or the client may have
+ knowledge of a relevant island of security which the recursive name
+ server does not share. In such cases, "protecting" a client which is
+ capable of performing its own signature validation from ever seeing
+ the "bad" data does not help the client.
+
+3.2.3 The AD bit
+
+ The name server side of a security-aware recursive name server MUST
+ NOT set the AD bit in a response unless the name server considers all
+ RRsets in the Answer and Authority sections of the response to be
+ authentic. The name server side SHOULD set the AD bit if and only if
+ the resolver side considers all RRsets in the Answer section and any
+ relevant negative response RRs in the Authority section to be
+ authentic. The resolver side MUST follow the procedure described in
+ Section 5 to determine whether the RRs in question are authentic.
+ However, for backwards compatibility, a recursive name server MAY set
+ the AD bit when a response includes unsigned CNAME RRs if those CNAME
+ RRs demonstrably could have been synthesized from an authentic DNAME
+ RR which is also included in the response according to the synthesis
+ rules described in [RFC2672].
+
+3.3 Example DNSSEC Responses
+
+ See Appendix B for example response packets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 19]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+4. Resolving
+
+ This section describes the behavior of entities that include
+ security-aware resolver functions. In many cases such functions will
+ be part of a security-aware recursive name server, but a stand-alone
+ security-aware resolver has many of the same requirements. Functions
+ specific to security-aware recursive name servers are described in
+ Section 3.2.
+
+4.1 EDNS Support
+
+ A security-aware resolver MUST include an EDNS [RFC2671] OPT
+ pseudo-RR with the DO [RFC3225] bit set to one when sending queries.
+
+ A security-aware resolver MUST support a message size of at least
+ 1220 octets, SHOULD support a message size of 4000 octets, and MUST
+ advertise the supported message size using the "sender's UDP payload
+ size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST
+ handle fragmented UDP packets correctly regardless of whether any
+ such fragmented packets were received via IPv4 or IPv6. Please see
+ [RFC3226] for discussion of these requirements.
+
+4.2 Signature Verification Support
+
+ A security-aware resolver MUST support the signature verification
+ mechanisms described in Section 5, and MUST apply them to every
+ received response except when:
+ o The security-aware resolver is part of a security-aware recursive
+ name server, and the response is the result of recursion on behalf
+ of a query received with the CD bit set;
+ o The response is the result of a query generated directly via some
+ form of application interface which instructed the security-aware
+ resolver not to perform validation for this query; or
+ o Validation for this query has been disabled by local policy.
+
+ A security-aware resolver's support for signature verification MUST
+ include support for verification of wildcard owner names.
+
+ Security aware resolvers MAY query for missing security RRs in an
+ attempt to perform validation; implementations that choose to do so
+ must be aware of the fact that the answers received may not be
+ sufficient to validate the original response.
+
+ When attempting to retrieve missing NSEC RRs which reside on the
+ parental side at a zone cut, a security-aware iterative-mode resolver
+ MUST query the name servers for the parent zone, not the child zone.
+
+ When attempting to retrieve a missing DS, a security-aware
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 20]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ iterative-mode resolver MUST query the name servers for the parent
+ zone, not the child zone. As explained in Section 3.1.4.1,
+ security-aware name servers need to apply special processing rules to
+ handle the DS RR, and in some situations the resolver may also need
+ to apply special rules to locate the name servers for the parent zone
+ if the resolver does not already have the parent's NS RRset. To
+ locate the parent NS RRset, the resolver can start with the
+ delegation name, strip off the leftmost label, and query for an NS
+ RRset by that name; if no NS RRset is present at that name, the
+ resolver then strips of the leftmost remaining label and retries the
+ query for that name, repeating this process of walking up the tree
+ until it either finds the NS RRset or runs out of labels.
+
+4.3 Determining Security Status of Data
+
+ A security-aware resolver MUST be able to determine whether or not it
+ should expect a particular RRset to be signed. More precisely, a
+ security-aware resolver must be able to distinguish between four
+ cases:
+
+ Secure: An RRset for which the resolver is able to build a chain of
+ signed DNSKEY and DS RRs from a trusted security anchor to the
+ RRset. In this case, the RRset should be signed, and is subject
+ to signature validation as described above.
+
+ Insecure: An RRset for which the resolver knows that it has no chain
+ of signed DNSKEY and DS RRs from any trusted starting point to the
+ RRset. This can occur when the target RRset lies in an unsigned
+ zone or in a descendent of an unsigned zone. In this case, the
+ RRset may or may not be signed, but the resolver will not be able
+ to verify the signature.
+
+ Bogus: An RRset for which the resolver believes that it ought to be
+ able to establish a chain of trust but is unable to do so, either
+ due to signatures that for some reason fail to validate or due to
+ missing data which the relevant DNSSEC RRs indicate should be
+ present. This case may indicate an attack, but may also indicate
+ a configuration error or some form of data corruption.
+
+ Indeterminate: An RRset for which the resolver is not able to
+ determine whether or not the RRset should be signed, because the
+ resolver is not able to obtain the necessary DNSSEC RRs. This can
+ occur when the security-aware resolver is not able to contact
+ security-aware name servers for the relevant zones.
+
+4.4 Configured Trust Anchors
+
+ A security-aware resolver MUST be capable of being configured with at
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 21]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ least one trusted public key or DS RR, and SHOULD be capable of being
+ configured with multiple trusted public keys or DS RRs. Since a
+ security-aware resolver will not be able to validate signatures
+ without such a configured trust anchor, the resolver SHOULD have some
+ reasonably robust mechanism for obtaining such keys when it boots;
+ examples of such a mechanism would be some form of non-volatile
+ storage (such as a disk drive) or some form of trusted local network
+ configuration mechanism.
+
+ Note that trust anchors also covers key material that is updated in a
+ secure manner. This secure manner could be through physical media, a
+ key exchange protocol, or some other out of band means.
+
+4.5 Response Caching
+
+ A security-aware resolver SHOULD cache each response as a single
+ atomic entry containing the entire answer, including the named RRset
+ and any associated DNSSEC RRs. The resolver SHOULD discard the
+ entire atomic entry when any of the RRs contained in it expire. In
+ most cases the appropriate cache index for the atomic entry will be
+ the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
+ form described in Section 3.1.3.2 the appropriate cache index will be
+ the double <QNAME,QCLASS>.
+
+4.6 Handling of the CD and AD bits
+
+ A security-aware resolver MAY set the CD bit in a query to one in
+ order to indicate that the resolver takes responsibility for
+ performing whatever authentication its local policy requires on the
+ RRsets in the response. See Section 3.2 for the effect this bit has
+ on the behavior of security-aware recursive name servers.
+
+ A security-aware resolver MUST zero the AD bit when composing query
+ messages to protect against buggy name servers which blindly copy
+ header bits which they do not understand from the query message to
+ the response message.
+
+ A resolver MUST disregard the meaning of the CD and AD bits in a
+ response unless the response was obtained using a secure channel or
+ the resolver was specifically configured to regard the message header
+ bits without using a secure channel.
+
+4.7 Caching BAD Data
+
+ While many validation errors will be transient, some are likely to be
+ more persistent, such as those caused by administrative error
+ (failure to re-sign a zone, clock skew, and so forth). Since
+ requerying will not help in these cases, validating resolvers might
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 22]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ generate a significant amount of unnecessary DNS traffic as a result
+ of repeated queries for RRsets with persistent validation failures.
+
+ To prevent such unnecessary DNS traffic, security-aware resolvers MAY
+ cache data with invalid signatures, with some restrictions.
+ Conceptually, caching such data is similar to negative caching
+ [RFC2308], except that instead of caching a valid negative response,
+ the resolver is caching the fact that a particular answer failed to
+ validate. This document refers to a cache of data with invalid
+ signatures as a "BAD cache".
+
+ Resolvers which implement a BAD cache MUST take steps to prevent the
+ cache from being useful as a denial-of-service attack amplifier. In
+ particular:
+ o Since RRsets which fail to validate do not have trustworthy TTLs,
+ the implementation MUST assign a TTL. This TTL SHOULD be small,
+ in order to mitigate the effect of caching the results of an
+ attack.
+ o In order to prevent caching of a transient validation failure
+ (which might be the result of an attack), resolvers SHOULD track
+ queries that result in validation failures, and SHOULD only answer
+ from the BAD cache after the number of times that responses to
+ queries for that particular <QNAME, QTYPE, QCLASS> have failed to
+ validate exceeds a threshold value.
+
+ Resolvers MUST NOT return RRsets from the BAD cache unless the
+ resolver is not required to validate the signatures of the RRsets in
+ question under the rules given in Section 4.2 of this document. See
+ Section 3.2.2 for discussion of how the responses returned by a
+ security-aware recursive name server interact with a BAD cache.
+
+4.8 Synthesized CNAMEs
+
+ A validating security-aware resolver MUST treat the signature of a
+ valid signed DNAME RR as also covering unsigned CNAME RRs which could
+ have been synthesized from the DNAME RR as described in [RFC2672], at
+ least to the extent of not rejecting a response message solely
+ because it contains such CNAME RRs. The resolver MAY retain such
+ CNAME RRs in its cache or in the answers it hands back, but is not
+ required to do so.
+
+4.9 Stub resolvers
+
+ A security-aware stub resolver MUST support the DNSSEC RR types, at
+ least to the extent of not mishandling responses just because they
+ contain DNSSEC RRs.
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 23]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+4.9.1 Handling of the DO Bit
+
+ A non-validating security-aware stub resolver MAY include the DNSSEC
+ RRs returned by a security-aware recursive name server as part of the
+ data that the stub resolver hands back to the application which
+ invoked it but is not required to do so. A non-validating stub
+ resolver that wishes to do this will need to set the DO bit in
+ receive DNSSEC RRs from the recursive name server.
+
+ A validating security-aware stub resolver MUST set the DO bit, since
+ otherwise it will not receive the DNSSEC RRs it needs to perform
+ signature validation.
+
+4.9.2 Handling of the CD Bit
+
+ A non-validating security-aware stub resolver SHOULD NOT set the CD
+ bit when sending queries unless requested by the application layer,
+ since by definition, a non-validating stub resolver depends on the
+ security-aware recursive name server to perform validation on its
+ behalf.
+
+ A validating security-aware stub resolver SHOULD set the CD bit,
+ since otherwise the security-aware recursive name server will answer
+ the query using the name server's local policy, which may prevent the
+ stub resolver from receiving data which would be acceptable to the
+ stub resolver's local policy.
+
+4.9.3 Handling of the AD Bit
+
+ A non-validating security-aware stub resolver MAY chose to examine
+ the setting of the AD bit in response messages that it receives in
+ order to determine whether the security-aware recursive name server
+ which sent the response claims to have cryptographically verified the
+ data in the Answer and Authority sections of the response message.
+ Note, however, that the responses received by a security-aware stub
+ resolver are heavily dependent on the local policy of the
+ security-aware recursive name server, so as a practical matter there
+ may be little practical value to checking the status of the AD bit
+ except perhaps as a debugging aid. In any case, a security-aware
+ stub resolver MUST NOT place any reliance on signature validation
+ allegedly performed on its behalf except when the security-aware stub
+ resolver obtained the data in question from a trusted security-aware
+ recursive name server via a secure channel.
+
+ A validating security-aware stub resolver SHOULD NOT examine the
+ setting of the AD bit in response messages, since, by definition, the
+ stub resolver performs its own signature validation regardless of the
+ setting of the AD bit.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 24]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+5. Authenticating DNS Responses
+
+ In order to use DNSSEC RRs for authentication, a security-aware
+ resolver requires configured knowledge of at least one authenticated
+ DNSKEY or DS RR. The process for obtaining and authenticating this
+ initial trust anchors is achieved via some external mechanism. For
+ example, a resolver could use some off-line authenticated exchange to
+ obtain a zone's DNSKEY RR or obtain a DS RR that identifies and
+ authenticates a zone's DNSKEY RR. The remainder of this section
+ assumes that the resolver has somehow obtained an initial set of
+ trust anchors.
+
+ An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
+ RRset. To authenticate an apex DNSKEY RRset using an initial key,
+ the resolver MUST:
+ 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY
+ RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
+ (DNSKEY RDATA bit 7) set to one.
+ 2. Verify that there is some RRSIG RR that covers the apex DNSKEY
+ RRset, and that the combination of the RRSIG RR and the initial
+ DNSKEY RR authenticates the DNSKEY RRset. The process for using
+ an RRSIG RR to authenticate an RRset is described in Section 5.3.
+
+ Once the resolver has authenticated the apex DNSKEY RRset using an
+ initial DNSKEY RR, delegations from that zone can be authenticated
+ using DS RRs. This allows a resolver to start from an initial key,
+ and use DS RRsets to proceed recursively down the DNS tree obtaining
+ other apex DNSKEY RRsets. If the resolver were configured with a
+ root DNSKEY RR, and if every delegation had a DS RR associated with
+ it, then the resolver could obtain and validate any apex DNSKEY
+ RRset. The process of using DS RRs to authenticate referrals is
+ described in Section 5.2.
+
+ Once the resolver has authenticated a zone's apex DNSKEY RRset,
+ Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
+ DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
+ RRsets in the zone. Section 5.4 shows how the resolver can use
+ authenticated NSEC RRsets from the zone to prove that an RRset is not
+ present in the zone.
+
+ When a resolver indicates support for DNSSEC (by setting the DO bit),
+ a security-aware name server should attempt to provide the necessary
+ DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
+ However, a security-aware resolver may still receive a response that
+ that lacks the appropriate DNSSEC RRs, whether due to configuration
+ issues such as an upstream security-oblivious recursive name server
+ that accidentally interferes with DNSSEC RRs or due to a deliberate
+ attack in which an adversary forges a response, strips DNSSEC RRs
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 25]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ from a response, or modifies a query so that DNSSEC RRs appear not to
+ be requested. The absence of DNSSEC data in a response MUST NOT by
+ itself be taken as an indication that no authentication information
+ exists.
+
+ A resolver SHOULD expect authentication information from signed
+ zones. A resolver SHOULD believe that a zone is signed if the
+ resolver has been configured with public key information for the
+ zone, or if the zone's parent is signed and the delegation from the
+ parent contains a DS RRset.
+
+5.1 Special Considerations for Islands of Security
+
+ Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
+ zones for which it is not possible to construct an authentication
+ chain to the zone from its parent. Validating signatures within an
+ island of security requires the validator to have some other means of
+ obtaining an initial authenticated zone key for the island. If a
+ validator cannot obtain such a key, it SHOULD switch to operating as
+ if the zones in the island of security are unsigned.
+
+ All the normal processes for validating responses apply to islands of
+ security. The only difference between normal validation and
+ validation within an island of security is in how the validator
+ obtains a trust anchor for the authentication chain.
+
+5.2 Authenticating Referrals
+
+ Once the apex DNSKEY RRset for a signed parent zone has been
+ authenticated, DS RRsets can be used to authenticate the delegation
+ to a signed child zone. A DS RR identifies a DNSKEY RR in the child
+ zone's apex DNSKEY RRset, and contains a cryptographic digest of the
+ child zone's DNSKEY RR. A strong cryptographic digest algorithm
+ ensures that an adversary can not easily generate a DNSKEY RR that
+ matches the digest. Thus, authenticating the digest allows a
+ resolver to authenticate the matching DNSKEY RR. The resolver can
+ then use this child DNSKEY RR to authenticate the entire child apex
+ DNSKEY RRset.
+
+ Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
+ can be authenticated if all of the following hold:
+ o The DS RR has been authenticated using some DNSKEY RR in the
+ parent's apex DNSKEY RRset (see Section 5.3);
+ o The Algorithm and Key Tag in the DS RR match the Algorithm field
+ and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
+ RRset and, when hashed using the digest algorithm specified in the
+ DS RR's Digest Type field, results in a digest value that matches
+ the Digest field of the DS RR; and
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 26]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ o The matching DNSKEY RR in the child zone has the Zone Flag bit set
+ to one, the corresponding private key has signed the child zone's
+ apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
+ child zone's apex DNSKEY RRset.
+
+ If the referral from the parent zone did not contain a DS RRset, the
+ response should have included a signed NSEC RRset proving that no DS
+ RRset exists for the delegated name (see Section 3.1.4). A
+ security-aware resolver MUST query the name servers for the parent
+ zone for the DS RRset if the referral includes neither a DS RRset nor
+ a NSEC RRset proving that the DS RRset does not exist (see Section
+ 4).
+
+ If the validator authenticates an NSEC RRset that proves that no DS
+ RRset is present for this zone, then there is no authentication path
+ leading from the parent to the child. If the resolver has an initial
+ DNSKEY or DS RR that belongs to the child zone or to any delegation
+ below the child zone, this initial DNSKEY or DS RR MAY be used to
+ re-establish an authentication path. If no such initial DNSKEY or DS
+ RR exists, the validator can not authenticate RRsets in or below the
+ child zone.
+
+ If the validator does not support any of the algorithms listed in an
+ authenticated DS RRset, then the resolver has no supported
+ authentication path leading from the parent to the child. The
+ resolver should treat this case as it would the case of an
+ authenticated NSEC RRset proving that no DS RRset exists, as
+ described above.
+
+ Note that, for a signed delegation, there are two NSEC RRs associated
+ with the delegated name. One NSEC RR resides in the parent zone, and
+ can be used to prove whether a DS RRset exists for the delegated
+ name. The second NSEC RR resides in the child zone, and identifies
+ which RRsets are present at the apex of the child zone. The parent
+ NSEC RR and child NSEC RR can always be distinguished, since the SOA
+ bit will be set in the child NSEC RR and clear in the parent NSEC RR.
+ A security-aware resolver MUST use the parent NSEC RR when attempting
+ to prove that a DS RRset does not exist.
+
+ If the resolver does not support any of the algorithms listed in an
+ authenticated DS RRset, then the resolver will not be able to verify
+ the authentication path to the child zone. In this case, the
+ resolver SHOULD treat the child zone as if it were unsigned.
+
+5.3 Authenticating an RRset Using an RRSIG RR
+
+ A validator can use an RRSIG RR and its corresponding DNSKEY RR to
+ attempt to authenticate RRsets. The validator first checks the RRSIG
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 27]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ RR to verify that it covers the RRset, has a valid time interval, and
+ identifies a valid DNSKEY RR. The validator then constructs the
+ canonical form of the signed data by appending the RRSIG RDATA
+ (excluding the Signature Field) with the canonical form of the
+ covered RRset. Finally, the validator uses the public key and
+ signature to authenticate the signed data. Section 5.3.1, Section
+ 5.3.2, and Section 5.3.3 describe each step in detail.
+
+5.3.1 Checking the RRSIG RR Validity
+
+ A security-aware resolver can use an RRSIG RR to authenticate an
+ RRset if all of the following conditions hold:
+ o The RRSIG RR and the RRset MUST have the same owner name and the
+ same class;
+ o The RRSIG RR's Signer's Name field MUST be the name of the zone
+ that contains the RRset;
+ o The RRSIG RR's Type Covered field MUST equal the RRset's type;
+ o The number of labels in the RRset owner name MUST be greater than
+ or equal to the value in the RRSIG RR's Labels field;
+ o The validator's notion of the current time MUST be less than or
+ equal to the time listed in the RRSIG RR's Expiration field;
+ o The validator's notion of the current time MUST be greater than or
+ equal to the time listed in the RRSIG RR's Inception field;
+ o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
+ match the owner name, algorithm, and key tag for some DNSKEY RR in
+ the zone's apex DNSKEY RRset;
+ o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
+ RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
+ set to one.
+
+ It is possible for more than one DNSKEY RR to match the conditions
+ above. In this case, the validator cannot predetermine which DNSKEY
+ RR to use to authenticate the signature, MUST try each matching
+ DNSKEY RR until either the signature is validated or the validator
+ has run out of matching public keys to try.
+
+ Note that this authentication process is only meaningful if the
+ validator authenticates the DNSKEY RR before using it to validate
+ signatures. The matching DNSKEY RR is considered to be authentic if:
+ o The apex DNSKEY RRset containing the DNSKEY RR is considered
+ authentic; or
+ o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
+ and the DNSKEY RR either matches an authenticated DS RR from the
+ parent zone or matches a trust anchor.
+
+5.3.2 Reconstructing the Signed Data
+
+ Once the RRSIG RR has met the validity requirements described in
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 28]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ Section 5.3.1, the validator needs to reconstruct the original signed
+ data. The original signed data includes RRSIG RDATA (excluding the
+ Signature field) and the canonical form of the RRset. Aside from
+ being ordered, the canonical form of the RRset might also differ from
+ the received RRset due to DNS name compression, decremented TTLs, or
+ wildcard expansion. The validator should use the following to
+ reconstruct the original signed data:
+
+ signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
+
+ "|" denotes concatenation
+
+ RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+ with the Signature field excluded and the Signer's Name
+ in canonical form.
+
+ RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
+
+ name is calculated according to the function below
+
+ class is the RRset's class
+
+ type is the RRset type and all RRs in the class
+
+ OrigTTL is the value from the RRSIG Original TTL field
+
+ All names in the RDATA field are in canonical form
+
+ The set of all RR(i) is sorted into canonical order.
+
+ To calculate the name:
+ let rrsig_labels = the value of the RRSIG Labels field
+
+ let fqdn = RRset's fully qualified domain name in
+ canonical form
+
+ let fqdn_labels = Label count of the fqdn above.
+
+ if rrsig_labels = fqdn_labels,
+ name = fqdn
+
+ if rrsig_labels < fqdn_labels,
+ name = "*." | the rightmost rrsig_label labels of the
+ fqdn
+
+ if rrsig_labels > fqdn_labels
+ the RRSIG RR did not pass the necessary validation
+ checks and MUST NOT be used to authenticate this
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 29]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ RRset.
+
+ The canonical forms for names and RRsets are defined in
+ [I-D.ietf-dnsext-dnssec-records].
+
+ NSEC RRsets at a delegation boundary require special processing.
+ There are two distinct NSEC RRsets associated with a signed delegated
+ name. One NSEC RRset resides in the parent zone, and specifies which
+ RRset are present at the parent zone. The second NSEC RRset resides
+ at the child zone, and identifies which RRsets are present at the
+ apex in the child zone. The parent NSEC RRset and child NSEC RRset
+ can always be distinguished since only the child NSEC RRs will
+ specify an SOA RRset exists at the name. When reconstructing the
+ original NSEC RRset for the delegation from the parent zone, the NSEC
+ RRs MUST NOT be combined with NSEC RRs from the child zone, and when
+ reconstructing the original NSEC RRset for the apex of the child
+ zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
+ zone.
+
+ Note also that each of the two NSEC RRsets at a delegation point has
+ a corresponding RRSIG RR with an owner name matching the delegated
+ name, and each of these RRSIG RRs is authoritative data associated
+ with the same zone that contains the corresponding NSEC RRset. If
+ necessary, a resolver can tell these RRSIG RRs apart by checking the
+ Signer's Name field.
+
+5.3.3 Checking the Signature
+
+ Once the resolver has validated the RRSIG RR as described in Section
+ 5.3.1 and reconstructed the original signed data as described in
+ Section 5.3.2, the validator can attempt to use the cryptographic
+ signature to authenticate the signed data, and thus (finally!)
+ authenticate the RRset.
+
+ The Algorithm field in the RRSIG RR identifies the cryptographic
+ algorithm used to generate the signature. The signature itself is
+ contained in the Signature field of the RRSIG RDATA, and the public
+ key used to verify the signature is contained in the Public Key field
+ of the matching DNSKEY RR(s) (found in Section 5.3.1).
+ [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types
+ and provides pointers to the documents that define each algorithm's
+ use.
+
+ Note that it is possible for more than one DNSKEY RR to match the
+ conditions in Section 5.3.1. In this case, the validator can only
+ determine which DNSKEY RR by trying each matching public key until
+ the validator either succeeds in validating the signature or runs out
+ of keys to try.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 30]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ If the Labels field of the RRSIG RR is not equal to the number of
+ labels in the RRset's fully qualified owner name, then the RRset is
+ either invalid or the result of wildcard expansion. The resolver
+ MUST verify that wildcard expansion was applied properly before
+ considering the RRset to be authentic. Section 5.3.4 describes how
+ to determine whether a wildcard was applied properly.
+
+ If other RRSIG RRs also cover this RRset, the local resolver security
+ policy determines whether the resolver also needs to test these RRSIG
+ RRs, and determines how to resolve conflicts if these RRSIG RRs lead
+ to differing results.
+
+ If the resolver accepts the RRset as authentic, the validator MUST
+ set the TTL of the RRSIG RR and each RR in the authenticated RRset to
+ a value no greater than the minimum of:
+ o The RRset's TTL as received in the response;
+ o The RRSIG RR's TTL as received in the response;
+ o The value in the RRSIG RR's Original TTL field; and
+ o The difference of the RRSIG RR's Signature Expiration time and the
+ current time.
+
+5.3.4 Authenticating A Wildcard Expanded RRset Positive Response
+
+ If the number of labels in an RRset's owner name is greater than the
+ Labels field of the covering RRSIG RR, then the RRset and its
+ covering RRSIG RR were created as a result of wildcard expansion.
+ Once the validator has verified the signature as described in Section
+ 5.3, it must take additional steps to verify the non-existence of an
+ exact match or closer wildcard match for the query. Section 5.4
+ discusses these steps.
+
+ Note that the response received by the resolver should include all
+ NSEC RRs needed to authenticate the response (see Section 3.1.3).
+
+5.4 Authenticated Denial of Existence
+
+ A resolver can use authenticated NSEC RRs to prove that an RRset is
+ not present in a signed zone. Security-aware name servers should
+ automatically include any necessary NSEC RRs for signed zones in
+ their responses to security-aware resolvers.
+
+ Security-aware resolvers MUST first authenticate NSEC RRsets
+ according to the standard RRset authentication rules described in
+ Section 5.3, then apply the NSEC RRsets as follows:
+ o If the requested RR name matches the owner name of an
+ authenticated NSEC RR, then the NSEC RR's type bit map field lists
+ all RR types present at that owner name, and a resolver can prove
+ that the requested RR type does not exist by checking for the RR
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 31]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ type in the bit map. If the number of labels in an authenticated
+ NSEC RR's owner name equals the Labels field of the covering RRSIG
+ RR, then the existence of the NSEC RR proves that wildcard
+ expansion could not have been used to match the request.
+ o If the requested RR name would appear after an authenticated NSEC
+ RR's owner name and before the name listed in that NSEC RR's Next
+ Domain Name field according to the canonical DNS name order
+ defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
+ the requested name exist in the zone. However, it is possible
+ that a wildcard could be used to match the requested RR owner name
+ and type, so proving that the requested RRset does not exist also
+ requires proving that no possible wildcard RRset exists that could
+ have been used to generate a positive response.
+
+ To prove non-existence of an RRset, the resolver must be able to
+ verify both that the queried RRset does not exist and that no
+ relevant wildcard RRset exists. Proving this may require more than
+ one NSEC RRset from the zone. If the complete set of necessary NSEC
+ RRsets is not present in a response (perhaps due to message
+ truncation), then a security-aware resolver MUST resend the query in
+ order to attempt to obtain the full collection of NSEC RRs necessary
+ to verify non-existence of the requested RRset. As with all DNS
+ operations, however, the resolver MUST bound the work it puts into
+ answering any particular query.
+
+ Since a validated NSEC RR proves the existence of both itself and its
+ corresponding RRSIG RR, a validator MUST ignore the settings of the
+ NSEC and RRSIG bits in an NSEC RR.
+
+5.5 Resolver Behavior When Signatures Do Not Validate
+
+ If for whatever reason none of the RRSIGs can be validated, the
+ response SHOULD be considered BAD. If the validation was being done
+ to service a recursive query, the name server MUST return RCODE 2 to
+ the originating client. However, it MUST return the full response if
+ and only if the original query had the CD bit set. See also Section
+ 4.7 on caching responses that do not validate.
+
+5.6 Authentication Example
+
+ Appendix C shows an example the authentication process.
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 32]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+6. IANA Considerations
+
+ [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
+ considerations introduced by DNSSEC. The additional IANA
+ considerations discussed in this document:
+
+ [RFC2535] reserved the CD and AD bits in the message header. The
+ meaning of the AD bit was redefined in [RFC3655] and the meaning of
+ both the CD and AD bit are restated in this document. No new bits in
+ the DNS message header are defined in this document.
+
+ [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
+ and defined its use. The use is restated but not altered in this
+ document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 33]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+7. Security Considerations
+
+ This document describes how the DNS security extensions use public
+ key cryptography to sign and authenticate DNS resource record sets.
+ Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
+ security considerations related to DNSSEC; see
+ [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the
+ DNSSEC resource record types.
+
+ An active attacker who can set the CD bit in a DNS query message or
+ the AD bit in a DNS response message can use these bits to defeat the
+ protection which DNSSEC attempts to provide to security-oblivious
+ recursive-mode resolvers. For this reason, use of these control bits
+ by a security-aware recursive-mode resolver requires a secure
+ channel. See Section 3.2.2 and Section 4.9 for further discussion.
+
+ The protocol described in this document attempts to extend the
+ benefits of DNSSEC to security-oblivious stub resolvers. However,
+ since recovery from validation failures is likely to be specific to
+ particular applications, the facilities that DNSSEC provides for stub
+ resolvers may prove inadequate. Operators of security-aware
+ recursive name servers will need to pay close attention to the
+ behavior of the applications which use their services when choosing a
+ local validation policy; failure to do so could easily result in the
+ recursive name server accidentally denying service to the clients it
+ is intended to support.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 34]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+8. Acknowledgements
+
+ This document was created from the input and ideas of the members of
+ the DNS Extensions Working Group and working group mailing list. The
+ editors would like to express their thanks for the comments and
+ suggestions received during the revision of these security extension
+ specifications. While explicitly listing everyone who has
+ contributed during the decade during which DNSSEC has been under
+ development would be an impossible task,
+ [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
+ participants who were kind enough to comment on these documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 35]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+9. References
+
+9.1 Normative References
+
+ [I-D.ietf-dnsext-dnssec-intro]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "DNS Security Introduction and Requirements",
+ draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
+ 2004.
+
+ [I-D.ietf-dnsext-dnssec-records]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "Resource Records for DNS Security Extensions",
+ draft-ietf-dnsext-dnssec-records-08 (work in progress),
+ May 2004.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+ August 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+ 2672, August 1999.
+
+ [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+ 3225, December 2001.
+
+ [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+ message size requirements", RFC 3226, December 2001.
+
+9.2 Informative References
+
+ [I-D.ietf-dnsext-nsec-rdata]
+ Schlyter, J., "KEY RR Secure Entry Point Flag",
+ draft-ietf-dnsext-nsec-rdata-05 (work in progress), March
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 36]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ 2004.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, March 1998.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+ RR)", RFC 2930, September 2000.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+ [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+ Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+ [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
+ (RR)", RFC 3658, December 2003.
+
+
+Authors' Addresses
+
+ Roy Arends
+ Telematica Instituut
+ Drienerlolaan 5
+ 7522 NB Enschede
+ NL
+
+ EMail: roy.arends@telin.nl
+
+
+ Matt Larson
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ EMail: mlarson@verisign.com
+
+
+ Rob Austein
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ EMail: sra@isc.org
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 37]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ Dan Massey
+ USC Information Sciences Institute
+ 3811 N. Fairfax Drive
+ Arlington, VA 22203
+ USA
+
+ EMail: masseyd@isi.edu
+
+
+ Scott Rose
+ National Institute for Standards and Technology
+ 100 Bureau Drive
+ Gaithersburg, MD 20899-8920
+ USA
+
+ EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 38]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+Appendix A. Signed Zone Example
+
+ The following example shows a (small) complete signed zone.
+
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1081539377
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ 3600 RRSIG SOA 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+ 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+ vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+ DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+ jV7j86HyQgM5e7+miRAz8V01b0I= )
+ 3600 NS ns1.example.
+ 3600 NS ns2.example.
+ 3600 RRSIG NS 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+ EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+ 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+ RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+ 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+ 3600 MX 1 xx.example.
+ 3600 RRSIG MX 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
+ 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
+ VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
+ 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
+ W6OISukd1EQt7a0kygkg+PEDxdI= )
+ 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
+ 3600 RRSIG NSEC 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+ FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+ Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+ SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+ jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+ 3600 DNSKEY 256 3 5 (
+ AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
+ rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
+ k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
+ vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 39]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
+ )
+ 3600 DNSKEY 257 3 5 (
+ AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
+ LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
+ syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
+ RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
+ Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
+ )
+ 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
+ 20040409183619 9465 example.
+ ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
+ xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
+ XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
+ hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
+ NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
+ 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
+ DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
+ bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
+ eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
+ 7z5OXogYVaFzHKillDt3HRxHIZM= )
+ a.example. 3600 IN NS ns1.a.example.
+ 3600 IN NS ns2.a.example.
+ 3600 DS 57855 5 1 (
+ B6DCD485719ADCA18E5F3D48A2331627FDD3
+ 636B )
+ 3600 RRSIG DS 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+ kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+ EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+ Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+ 3600 NSEC ai.example. NS DS RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
+ U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
+ 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
+ BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
+ sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
+ ns1.a.example. 3600 IN A 192.0.2.5
+ ns2.a.example. 3600 IN A 192.0.2.6
+ ai.example. 3600 IN A 192.0.2.9
+ 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 40]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+ ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+ hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+ ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+ 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+ 3600 HINFO "KLH-10" "ITS"
+ 3600 RRSIG HINFO 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
+ e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
+ ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
+ AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
+ FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
+ 3600 AAAA 2001:db8::f00:baa9
+ 3600 RRSIG AAAA 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+ kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+ 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+ cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+ sZM6QjBBLmukH30+w1z3h8PUP2o= )
+ 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
+ CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
+ P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
+ 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
+ AhS+JOVfDI/79QtyTI0SaDWcg8U= )
+ b.example. 3600 IN NS ns1.b.example.
+ 3600 IN NS ns2.b.example.
+ 3600 NSEC ns1.example. NS RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+ 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+ xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+ 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+ vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+ ns1.b.example. 3600 IN A 192.0.2.7
+ ns2.b.example. 3600 IN A 192.0.2.8
+ ns1.example. 3600 IN A 192.0.2.1
+ 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+ 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+ im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+ +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 41]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ v/iVXSYC0b7mPSU+EOlknFpVECs= )
+ 3600 NSEC ns2.example. A RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+ 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+ jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+ ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+ IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+ ns2.example. 3600 IN A 192.0.2.2
+ 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+ Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+ yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+ 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+ rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+ 3600 NSEC *.w.example. A RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
+ VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
+ 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
+ l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
+ Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
+ *.w.example. 3600 IN MX 1 ai.example.
+ 3600 RRSIG MX 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+ f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+ tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+ TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+ 4kX18MMR34i8lC36SR5xBni8vHI= )
+ 3600 NSEC x.w.example. MX RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+ HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+ 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+ 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+ s1InQ2UoIv6tJEaaKkP701j8OLA= )
+ x.w.example. 3600 IN MX 1 xx.example.
+ 3600 RRSIG MX 5 3 3600 20040509183619 (
+ 20040409183619 38519 example.
+ Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+ XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+ H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+ kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 42]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+ 3600 NSEC x.y.w.example. MX RRSIG NSEC
+ 3600 RRSIG NSEC 5 3 3600 20040509183619 (
+ 20040409183619 38519 example.
+ aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
+ vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
+ mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
+ NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
+ IjgiM8PXkBQtxPq37wDKALkyn7Q= )
+ x.y.w.example. 3600 IN MX 1 xx.example.
+ 3600 RRSIG MX 5 4 3600 20040509183619 (
+ 20040409183619 38519 example.
+ k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
+ t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
+ q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
+ GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
+ +gLcMZBnHJ326nb/TOOmrqNmQQE= )
+ 3600 NSEC xx.example. MX RRSIG NSEC
+ 3600 RRSIG NSEC 5 4 3600 20040509183619 (
+ 20040409183619 38519 example.
+ OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+ ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+ xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+ a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+ QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+ xx.example. 3600 IN A 192.0.2.10
+ 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+ 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+ 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+ VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+ kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+ 3600 HINFO "KLH-10" "TOPS-20"
+ 3600 RRSIG HINFO 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
+ t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
+ BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
+ 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
+ RgNvuwbioFSEuv2pNlkq0goYxNY= )
+ 3600 AAAA 2001:db8::f00:baaa
+ 3600 RRSIG AAAA 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+ aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+ ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+ U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 43]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ xS9cL2QgW7FChw16mzlkH6/vsfs= )
+ 3600 NSEC example. A HINFO AAAA RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
+ 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
+ mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
+ asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
+ GghLahumFIpg4MO3LS/prgzVVWo= )
+
+ The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
+ Flags indicate that each of these DNSKEY RRs is a zone key. One of
+ these DNSKEY RRs also has the SEP flag set and has been used to sign
+ the apex DNSKEY RRset; this is the key which should be hashed to
+ generate a DS record to be inserted into the parent zone. The other
+ DNSKEY is used to sign all the other RRsets in the zone.
+
+ The zone includes a wildcard entry "*.w.example". Note that the name
+ "*.w.example" is used in constructing NSEC chains, and that the RRSIG
+ covering the "*.w.example" MX RRset has a label count of 2.
+
+ The zone also includes two delegations. The delegation to
+ "b.example" includes an NS RRset, glue address records, and an NSEC
+ RR; note that only the NSEC RRset is signed. The delegation to
+ "a.example" provides a DS RR; note that only the NSEC and DS RRsets
+ are signed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 44]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+Appendix B. Example Responses
+
+ The examples in this section show response messages using the signed
+ zone example in Appendix A.
+
+B.1 Answer
+
+ A successful query to an authoritative server.
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ x.w.example. IN MX
+
+ ;; Answer
+ x.w.example. 3600 IN MX 1 xx.example.
+ x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 (
+ 20040409183619 38519 example.
+ Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+ XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+ H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+ kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+ jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+
+ ;; Authority
+ example. 3600 NS ns1.example.
+ example. 3600 NS ns2.example.
+ example. 3600 RRSIG NS 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+ EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+ 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+ RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+ 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+
+ ;; Additional
+ xx.example. 3600 IN A 192.0.2.10
+ xx.example. 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+ 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+ 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+ VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+ kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+ xx.example. 3600 AAAA 2001:db8::f00:baaa
+ xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 45]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+ ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+ U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+ xS9cL2QgW7FChw16mzlkH6/vsfs= )
+ ns1.example. 3600 IN A 192.0.2.1
+ ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+ 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+ im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+ +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+ v/iVXSYC0b7mPSU+EOlknFpVECs= )
+ ns2.example. 3600 IN A 192.0.2.2
+ ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+ Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+ yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+ 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+ rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+
+
+B.2 Name Error
+
+ An authoritative name error. The NSEC RRs prove that the name does
+ not exist and that no covering wildcard exists.
+
+ ;; Header: QR AA DO RCODE=3
+ ;;
+ ;; Question
+ ml.example. IN A
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1081539377
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+ 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+ vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 46]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+ jV7j86HyQgM5e7+miRAz8V01b0I= )
+ b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
+ b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+ 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+ xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+ 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+ vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+ example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
+ example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+ FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+ Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+ SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+ jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+ ;; Additional
+ ;; (empty)
+
+
+B.3 No Data Error
+
+ A "NODATA" response. The NSEC RR proves that the name exists and
+ that the requested RR type does not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 47]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ ns1.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1081539377
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+ 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+ vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+ DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+ jV7j86HyQgM5e7+miRAz8V01b0I= )
+ ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
+ ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+ 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+ jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+ ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+ IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+
+ ;; Additional
+ ;; (empty)
+
+
+B.4 Referral to Signed Zone
+
+ Referral to a signed zone. The DS RR contains the data which the
+ resolver will need to validate the corresponding DNSKEY RR in the
+ child zone's apex.
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 48]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ ;; Header: QR DO RCODE=0
+ ;;
+ ;; Question
+ mc.a.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ a.example. 3600 IN NS ns1.a.example.
+ a.example. 3600 IN NS ns2.a.example.
+ a.example. 3600 DS 57855 5 1 (
+ B6DCD485719ADCA18E5F3D48A2331627FDD3
+ 636B )
+ a.example. 3600 RRSIG DS 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+ kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+ EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+ Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+
+ ;; Additional
+ ns1.a.example. 3600 IN A 192.0.2.5
+ ns2.a.example. 3600 IN A 192.0.2.6
+
+
+B.5 Referral to Unsigned Zone
+
+ Referral to an unsigned zone. The NSEC RR proves that no DS RR for
+ this delegation exists in the parent zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 49]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ ;; Header: QR DO RCODE=0
+ ;;
+ ;; Question
+ mc.b.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ b.example. 3600 IN NS ns1.b.example.
+ b.example. 3600 IN NS ns2.b.example.
+ b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
+ b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+ 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+ xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+ 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+ vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+
+ ;; Additional
+ ns1.b.example. 3600 IN A 192.0.2.7
+ ns2.b.example. 3600 IN A 192.0.2.8
+
+
+B.6 Wildcard Expansion
+
+ A successful query which was answered via wildcard expansion. The
+ label count in the answer's RRSIG RR indicates that a wildcard RRset
+ was expanded to produce this response, and the NSEC RR proves that no
+ closer match exists in the zone.
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ a.z.w.example. IN MX
+
+ ;; Answer
+ a.z.w.example. 3600 IN MX 1 ai.example.
+ a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+ f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+ tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+ TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+ 4kX18MMR34i8lC36SR5xBni8vHI= )
+
+ ;; Authority
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 50]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ example. 3600 NS ns1.example.
+ example. 3600 NS ns2.example.
+ example. 3600 RRSIG NS 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+ EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+ 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+ RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+ 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+ x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
+ x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
+ 20040409183619 38519 example.
+ OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+ ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+ xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+ a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+ QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+
+ ;; Additional
+ ai.example. 3600 IN A 192.0.2.9
+ ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+ ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+ hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+ ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+ 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+ ai.example. 3600 AAAA 2001:db8::f00:baa9
+ ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+ kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+ 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+ cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+ sZM6QjBBLmukH30+w1z3h8PUP2o= )
+
+
+B.7 Wildcard No Data Error
+
+ A "NODATA" response for a name covered by a wildcard. The NSEC RRs
+ prove that the matching wildcard name does not have any RRs of the
+ requested type and that no closer match exists in the zone.
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ a.z.w.example. IN AAAA
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 51]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1081539377
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+ 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+ vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+ DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+ jV7j86HyQgM5e7+miRAz8V01b0I= )
+ x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
+ x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
+ 20040409183619 38519 example.
+ OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+ ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+ xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+ a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+ QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+ *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
+ *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+ HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+ 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+ 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+ s1InQ2UoIv6tJEaaKkP701j8OLA= )
+
+ ;; Additional
+ ;; (empty)
+
+
+B.8 DS Child Zone No Data Error
+
+ A "NODATA" response for a QTYPE=DS query which was mistakenly sent to
+ a name server for the child zone.
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 52]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ example. IN DS
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1081539377
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+ 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+ vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+ DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+ jV7j86HyQgM5e7+miRAz8V01b0I= )
+ example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
+ example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+ FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+ Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+ SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+ jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+ ;; Additional
+ ;; (empty)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 53]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+Appendix C. Authentication Examples
+
+ The examples in this section show how the response messages in
+ Appendix B are authenticated.
+
+C.1 Authenticating An Answer
+
+ The query in section Appendix B.1 returned an MX RRset for
+ "x.w.example.com". The corresponding RRSIG indicates the MX RRset
+ was signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
+ The resolver needs the corresponding DNSKEY RR in order to
+ authenticate this answer. The discussion below describes how a
+ resolver might obtain this DNSKEY RR.
+
+ The RRSIG indicates the original TTL of the MX RRset was 3600 and,
+ for the purpose of authentication, the current TTL is replaced by
+ 3600. The RRSIG labels field value of 3 indicates the answer was not
+ the result of wildcard expansion. The "x.w.example.com" MX RRset is
+ placed in canonical form and, assuming the current time falls between
+ the signature inception and expiration dates, the signature is
+ authenticated.
+
+C.1.1 Authenticating the example DNSKEY RR
+
+ This example shows the logical authentication process that starts
+ from the a configured root DNSKEY (or DS RR) and moves down the tree
+ to authenticate the desired "example" DNSKEY RR. Note the logical
+ order is presented for clarity and an implementation may choose to
+ construct the authentication as referrals are received or may choose
+ to construct the authentication chain only after all RRsets have been
+ obtained, or in any other combination it sees fit. The example here
+ demonstrates only the logical process and does not dictate any
+ implementation rules.
+
+ We assume the resolver starts with an configured DNSKEY RR for the
+ root zone (or a configured DS RR for the root zone). The resolver
+ checks this configured DNSKEY RR is present in the root DNSKEY RRset
+ (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this
+ DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime
+ is valid. If all these conditions are met, all keys in the DNSKEY
+ RRset are considered authenticated. The resolver then uses one (or
+ more) of the root DNSKEY RRs to authenticate the "example" DS RRset.
+ Note the resolver may need to query the root zone to obtain the root
+ DNSKEY RRset or "example" DS RRset.
+
+ Once the DS RRset has been authenticated using the root DNSKEY, the
+ resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
+ RR that matches one of the authenticated "example" DS RRs. If such a
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 54]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ matching "example" DNSKEY is found, the resolver checks this DNSKEY
+ RR has signed the "example" DNSKEY RRset and the signature lifetime
+ is valid. If all these conditions are met, all keys in the "example"
+ DNSKEY RRset are considered authenticated.
+
+ Finally the resolver checks that some DNSKEY RR in the "example"
+ DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY
+ is used to authenticated the RRSIG included in the response. If
+ multiple "example" DNSKEY RRs match this algorithm and key tag, then
+ each DNSKEY RR is tried and the answer is authenticated if any of the
+ matching DNSKEY RRs validates the signature as described above.
+
+C.2 Name Error
+
+ The query in section Appendix B.2 returned NSEC RRs that prove the
+ requested data does not exist and no wildcard applies. The negative
+ reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
+ authenticated in a manner identical to that of the MX RRset discussed
+ above.
+
+C.3 No Data Error
+
+ The query in section Appendix B.3 returned an NSEC RR that proves the
+ requested name exists, but the requested RR type does not exist. The
+ negative reply is authenticated by verifying the NSEC RR. The NSEC
+ RR is authenticated in a manner identical to that of the MX RRset
+ discussed above.
+
+C.4 Referral to Signed Zone
+
+ The query in section Appendix B.4 returned a referral to the signed
+ "a.example." zone. The DS RR is authenticated in a manner identical
+ to that of the MX RRset discussed above. This DS RR is used to
+ authenticate the "a.example" DNSKEY RRset.
+
+ Once the "a.example" DS RRset has been authenticated using the
+ "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
+ for some "a.example" DNSKEY RR that matches the DS RR. If such a
+ matching "a.example" DNSKEY is found, the resolver checks this DNSKEY
+ RR has signed the "a.example" DNSKEY RRset and the signature lifetime
+ is valid. If all these conditions are met, all keys in the
+ "a.example" DNSKEY RRset are considered authenticated.
+
+C.5 Referral to Unsigned Zone
+
+ The query in section Appendix B.5 returned a referral to an unsigned
+ "b.example." zone. The NSEC proves that no authentication leads from
+ "example" to "b.example" and the NSEC RR is authenticated in a manner
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 55]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ identical to that of the MX RRset discussed above.
+
+C.6 Wildcard Expansion
+
+ The query in section Appendix B.6 returned an answer that was
+ produced as a result of wildcard expansion. The RRset expanded as the
+ similar to The corresponding RRSIG indicates the MX RRset was signed
+ by an "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG
+ indicates the original TTL of the MX RRset was 3600 and, for the
+ purpose of authentication, the current TTL is replaced by 3600. The
+ RRSIG labels field value of 2 indicates the answer the result of
+ wildcard expansion since the "a.z.w.example" name contains 4 labels.
+ The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset
+ is placed in canonical form and, assuming the current time falls
+ between the signature inception and expiration dates, the signature
+ is authenticated.
+
+ The NSEC proves that no closer match (exact or closer wildcard) could
+ have been used to answer this query and the NSEC RR must also be
+ authenticated before the answer is considered valid.
+
+C.7 Wildcard No Data Error
+
+ The query in section Appendix B.7 returned NSEC RRs that prove the
+ requested data does not exist and no wildcard applies. The negative
+ reply is authenticated by verifying both NSEC RRs.
+
+C.8 DS Child Zone No Data Error
+
+ The query in section Appendix B.8 returned NSEC RRs that shows the
+ requested was answered by a child server ("example" server). The
+ NSEC RR indicates the presence of an SOA RR, showing the answer is
+ from the child . Queries for the "example" DS RRset should be sent
+ to the parent servers ("root" servers).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 56]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 57]
+
+Internet-Draft DNSSEC Protocol Modifications May 2004
+
+
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 58]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt index cfd3567f..3ca99bfb 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt @@ -1,2073 +1,1961 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: August 16, 2004 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - February 16, 2004 - - - Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-07 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 16, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document is part of a family of documents that describes the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of resource records and protocol modifications that - provide source authentication for the DNS. This document defines the - public key (DNSKEY), delegation signer (DS), resource record digital - - - -Arends, et al. Expires August 16, 2004 [Page 1] - -Internet-Draft DNSSEC Resource Records February 2004 - - - signature (RRSIG), and authenticated denial of existence (NSEC) - resource records. The purpose and format of each resource record is - described in detail, and an example of each resource record is given. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 - 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 - 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 6 - 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 - 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7 - 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7 - 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7 - 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . . . . 7 - 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . . 7 - 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . . 8 - 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 9 - 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . . 9 - 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10 - 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10 - 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11 - 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11 - 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11 - 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 12 - 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 - 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 13 - 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13 - 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15 - 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 - 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15 - 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . . . . 16 - 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 17 - 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 17 - 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17 - 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 19 - 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 19 - 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 20 - 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 20 - - - -Arends, et al. Expires August 16, 2004 [Page 2] - -Internet-Draft DNSSEC Resource Records February 2004 - - - 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 20 - 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 20 - 5.2 Processing of DS RRs When Validating Responses . . . . . . . 20 - 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 21 - 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 21 - 6. Canonical Form and Order of Resource Records . . . . . . . . 22 - 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 22 - 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 22 - 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 23 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 - 8. Security Considerations . . . . . . . . . . . . . . . . . . 26 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 - Normative References . . . . . . . . . . . . . . . . . . . . 28 - Informative References . . . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 - A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 32 - A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 32 - A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 32 - A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 33 - B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 34 - B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 35 - Intellectual Property and Copyright Statements . . . . . . . 36 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 3] - -Internet-Draft DNSSEC Resource Records February 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduce four new DNS resource - record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the - purpose of each resource record (RR), the RR's RDATA format, and its - presentation format (ASCII representation). - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs - that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 - [RFC2308]. - - This document is part of a family of documents that define the DNS - security extensions. The DNS security extensions (DNSSEC) are a - collection of resource records and DNS protocol modifications that - add source authentication and data integrity to the Domain Name - System (DNS). An introduction to DNSSEC and definitions of common - terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description - of DNS protocol modifications can be found in - [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC - resource records. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -1.3 Editors' Notes - -1.3.1 Open Technical Issues - - The cryptographic algorithm types (Appendix A) requires input from - the working group. The DSA algorithm was moved to OPTIONAL. This - had strong consensus in workshops and various discussions and a - separate Internet-Draft solely to move DSA from MANDATORY to OPTIONAL - seemed excessive. This draft solicits input on that proposed change. - -1.3.2 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where no RFC that defines the correct behavior, or if there's - more than one applicable RFC and the definitions conflict, please - post the issue to namedroppers. - - - -Arends, et al. Expires August 16, 2004 [Page 4] - -Internet-Draft DNSSEC Resource Records February 2004 - - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - -1.3.3 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to find - the incorrect text quickly. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 5] - -Internet-Draft DNSSEC Resource Records February 2004 - - -2. The DNSKEY Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). The public keys are stored in DNSKEY - resource records and are used in the DNSSEC authentication process - described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its - authoritative RRsets using a private key and stores the corresponding - public key in a DNSKEY RR. A resolver can then use the public key to - authenticate signatures covering the RRsets in the zone. - - The DNSKEY RR is not intended as a record for storing arbitrary - public keys, and MUST NOT be used to store certificates or public - keys that do not directly relate to the DNS infrastructure. - - The Type value for the DNSKEY RR type is 48. - - The DNSKEY RR is class independent. - - The DNSKEY RR has no special TTL requirements. - -2.1 DNSKEY RDATA Wire Format - - The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 - octet Protocol Field, a 1 octet Algorithm Field, and the Public Key - Field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Protocol | Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Public Key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -2.1.1 The Flags Field - - Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, - then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner - name MUST be the name of a zone. If bit 7 has value 0, then the - DNSKEY record holds some other type of DNS public key, such as a - public key used by TKEY and MUST NOT be used to verify RRSIGs that - cover RRsets. - - Bit 15 of the Flags field is the Secure Entry Point flag, described - in [I-D.ietf-dnsext-keyrr-key-signing-flag]. If bit 15 has value 1, - - - -Arends, et al. Expires August 16, 2004 [Page 6] - -Internet-Draft DNSSEC Resource Records February 2004 - - - then the DNSKEY record holds a key intended for use as a secure entry - point. This flag is only intended to be to a hint to zone signing or - debugging software as to the intended use of this DNSKEY record; - security-aware resolvers MUST NOT alter their behavior during the - signature validation process in any way based on the setting of this - bit. - - Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon - creation of the DNSKEY RR, and MUST be ignored upon reception. - -2.1.2 The Protocol Field - - The Protocol Field MUST have value 3 and MUST be treated as invalid - during signature verification if found to be some value other than 3. - -2.1.3 The Algorithm Field - - The Algorithm field identifies the public key's cryptographic - algorithm and determines the format of the Public Key field. A list - of DNSSEC algorithm types can be found in Appendix A.1 - -2.1.4 The Public Key Field - - The Public Key Field holds the public key material. The format - depends on the algorithm of the key being stored and are described in - separate documents. - -2.1.5 Notes on DNSKEY RDATA Design - - Although the Protocol Field always has value 3, it is retained for - backward compatibility with early versions of the KEY record. - -2.2 The DNSKEY RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Flag field MUST be represented as an unsigned decimal integer - with a value of 0, 256, or 257. - - The Protocol Field MUST be represented as an unsigned decimal integer - with a value of 3. - - The Algorithm field MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix - A.1. - - The Public Key field MUST be represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - - - -Arends, et al. Expires August 16, 2004 [Page 7] - -Internet-Draft DNSSEC Resource Records February 2004 - - - definition of Base64 encoding, see [RFC1521] Section 5.2. - -2.3 DNSKEY RR Example - - The following DNSKEY RR stores a DNS zone key for example.com. - - example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 - Cbl+BBZH4b/0PY1kxkmvHjcZc8no - kfzj31GajIQKY+5CptLr3buXA10h - WqTkF7H6RfoRqXQeogmMHfpftf6z - Mv1LyBUgia7za6ZEzOJBOztyvhjL - 742iU/TpPSEDhm2SNKLijfUppn1U - aNvv4w== ) - - The first four text fields specify the owner name, TTL, Class, and RR - type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in - the Flags field has value 1. Value 3 is the fixed Protocol value. - Value 5 indicates the public key algorithm. Appendix A.1 identifies - algorithm type 5 as RSA/SHA1 and indicates that the format of the - RSA/SHA1 public key field is defined in [RFC3110]. The remaining - text is a Base64 encoding of the public key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 8] - -Internet-Draft DNSSEC Resource Records February 2004 - - -3. The RRSIG Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). Digital signatures are stored in - RRSIG resource records and are used in the DNSSEC authentication - process described in [I-D.ietf-dnsext-dnssec-protocol]. A - security-aware resolver can use these RRSIG RRs to authenticate - RRsets from the zone. The RRSIG RR MUST only be used to carry - verification material (digital signatures) used to secure DNS - operations. - - An RRSIG record contains the signature for an RRset with a particular - name, class, and type. The RRSIG RR specifies a validity interval - for the signature and uses the Algorithm, the Signer's Name, and the - Key Tag to identify the DNSKEY RR containing the public key that a - resolver can use to verify the signature. - - Because every authoritative RRset in a zone must be protected by a - digital signature, RRSIG RRs must be present for names containing a - CNAME RR. This is a change to the traditional DNS specification - [RFC1034] that stated that if a CNAME is present for a name, it is - the only type allowed at that name. A RRSIG and NSEC (see Section 4) - MUST exist for the same name as a CNAME resource record in a secure - zone. - - The Type value for the RRSIG RR type is 46. - - The RRSIG RR is class independent. - - An RRSIG RR MUST have the same class as the RRset it covers. - - The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset - it covers. This is an exception to the [RFC2181] rules for TTL - values of individual RRs within a RRset: individual RRSIG with the - same owner name will have different TTL values if the RRsets that - they cover have different TTL values. - -3.1 RRSIG RDATA Wire Format - - The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a - 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original - TTL field, a 4 octet Signature Expiration field, a 4 octet Signature - Inception field, a 2 octet Key tag, the Signer's Name field, and the - Signature field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Arends, et al. Expires August 16, 2004 [Page 9] - -Internet-Draft DNSSEC Resource Records February 2004 - - - | Type Covered | Algorithm | Labels | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Original TTL | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Expiration | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Inception | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Signature / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 The Type Covered Field - - The Type Covered field identifies the type of the RRset which is - covered by this RRSIG record. - -3.1.2 The Algorithm Number Field - - The Algorithm Number field identifies the cryptographic algorithm - used to create the signature. A list of DNSSEC algorithm types can - be found in Appendix A.1 - -3.1.3 The Labels Field - - The Labels field specifies the number of labels in the original RRSIG - RR owner name. The significance of this field is that from it a - verifier can determine if the answer was synthesized from a wildcard. - If so, it can be used to determine what owner name was used in - generating the signature. - - To validate a signature, the validator needs the original owner name - that was used to create the signature. If the original owner name - contains a wildcard label ("*"), the owner name may have been - expanded by the server during the response process, in which case the - validator will need to reconstruct the original owner name in order - to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] - describes how to use the Labels field to reconstruct the original - owner name. - - The value of the Labels field MUST NOT count either the null (root) - label that terminates the owner name or the wildcard label (if - - - -Arends, et al. Expires August 16, 2004 [Page 10] - -Internet-Draft DNSSEC Resource Records February 2004 - - - present). The value of the Labels field MUST be less than or equal - to the number of labels in the RRSIG owner name. For example, - "www.example.com." has a Labels field value of 3, and - "*.example.com." has a Labels field value of 2. Root (".") has a - Labels field value of 0. - - Although the wildcard label is not included in the count stored in - the Labels field of the RRSIG RR, the wildcard label is part of the - RRset's owner name when generating or verifying the signature. - -3.1.4 Original TTL Field - - The Original TTL field specifies the TTL of the covered RRset as it - appears in the authoritative zone. - - The Original TTL field is necessary because a caching resolver - decrements the TTL value of a cached RRset. In order to validate a - signature, a resolver requires the original TTL. - [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original - TTL field value to reconstruct the original TTL. - -3.1.5 Signature Expiration and Inception Fields - - The Signature Expiration and Inception fields specify a validity - period for the signature. The RRSIG record MUST NOT be used for - authentication prior to the inception date and MUST NOT be used for - authentication after the expiration date. - - Signature Expiration and Inception field values are in POSIX.1 time - format: a 32-bit unsigned number of seconds elapsed since 1 January - 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The - longest interval which can be expressed by this format without - wrapping is approximately 136 years. An RRSIG RR can have an - Expiration field value which is numerically smaller than the - Inception field value if the expiration field value is near the - 32-bit wrap-around point or if the signature is long lived. Because - of this, all comparisons involving these fields MUST use "Serial - number arithmetic" as defined in [RFC1982]. As a direct consequence, - the values contained in these fields cannot refer to dates more than - 68 years in either the past or the future. - -3.1.6 The Key Tag Field - - The Key Tag field contains the key tag value of the DNSKEY RR that - validates this signature. Appendix B explains how to calculate Key - Tag values. - - - - - -Arends, et al. Expires August 16, 2004 [Page 11] - -Internet-Draft DNSSEC Resource Records February 2004 - - -3.1.7 The Signer's Name Field - - The Signer's Name field value identifies the owner name of the DNSKEY - RR which a security-aware resolver should use to validate this - signature. The Signer's Name field MUST contain the name of the zone - of the covered RRset. A sender MUST NOT use DNS name compression on - the Signer's Name field when transmitting a RRSIG RR. A receiver - which receives an RRSIG RR containing a compressed Signer's Name - field SHOULD decompress the field value. - -3.1.8 The Signature Field - - The Signature field contains the cryptographic signature which covers - the RRSIG RDATA (excluding the Signature field) and the RRset - specified by the RRSIG owner name, RRSIG class, and RRSIG Type - Covered field. The format of this field depends on the algorithm in - use and these formats are described in separate companion documents. - -3.1.8.1 Signature Calculation - - A signature covers the RRSIG RDATA (excluding the Signature Field) - and covers the data RRset specified by the RRSIG owner name, RRSIG - class, and RRSIG Type Covered fields. The RRset is in canonical form - (see Section 6) and the set RR(1),...RR(n) is signed as follows: - - signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where - - "|" denotes concatenation; - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signer's Name field in canonical form and - the Signature field excluded; - - RR(i) = owner | class | type | TTL | RDATA length | RDATA; - - "owner" is the fully qualified owner name of the RRset in - canonical form (for RRs with wildcard owner names, the - wildcard label is included in the owner name); - - Each RR MUST have the same owner name as the RRSIG RR; - - Each RR MUST have the same class as the RRSIG RR; - - Each RR in the RRset MUST have the RR type listed in the - RRSIG RR's Type Covered field; - - Each RR in the RRset MUST have the TTL listed in the - RRSIG Original TTL Field; - - - -Arends, et al. Expires August 16, 2004 [Page 12] - -Internet-Draft DNSSEC Resource Records February 2004 - - - Any DNS names in the RDATA field of each RR MUST be in - canonical form; and - - The RRset MUST be sorted in canonical order. - - -3.2 The RRSIG RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Type Covered field value MUST be represented either as an - unsigned decimal integer or as the mnemonic for the covered RR type. - - The Algorithm field value MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix - A.1. - - The Labels field value MUST be represented as an unsigned decimal - integer. - - The Original TTL field value MUST be represented as an unsigned - decimal integer. - - The Signature Expiration Time and Inception Time field values MUST be - represented in the form YYYYMMDDHHmmSS in UTC, where: - - YYYY is the year (0000-9999, but see Section 3.1.5); - - MM is the month number (01-12); - - DD is the day of the month (01-31); - - HH is the hour in 24 hours notation (00-23); - - mm is the minute (00-59); - - SS is the second (00-59). - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Signer's Name field value MUST be represented as a domain name. - - The Signature field is represented as a Base64 encoding of the - signature. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding see [RFC1521] Section 5.2. - -3.3 RRSIG RR Example - - - - -Arends, et al. Expires August 16, 2004 [Page 13] - -Internet-Draft DNSSEC Resource Records February 2004 - - - The following an RRSIG RR stores the signature for the A RRset of - host.example.com: - - host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( - 20030220173103 2642 example.com. - oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr - PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o - B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t - GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG - J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) - - The first four fields specify the owner name, TTL, Class, and RR type - (RRSIG). The "A" represents the Type Covered field. The value 5 - identifies the algorithm used (RSA/SHA1) to create the signature. - The value 3 is the number of Labels in the original owner name. The - value 86400 in the RRSIG RDATA is the Original TTL for the covered A - RRset. 20030322173103 and 20030220173103 are the expiration and - inception dates, respectively. 2642 is the Key Tag, and example.com. - is the Signer's Name. The remaining text is a Base64 encoding of the - signature. - - Note that combination of RRSIG RR owner name, class, and Type Covered - indicate that this RRSIG covers the "host.example.com" A RRset. The - Label value of 3 indicates that no wildcard expansion was used. The - Algorithm, Signer's Name, and Key Tag indicate this signature can be - authenticated using an example.com zone DNSKEY RR whose algorithm is - 5 and key tag is 2642. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 14] - -Internet-Draft DNSSEC Resource Records February 2004 - - -4. The NSEC Resource Record - - The NSEC resource record lists two separate things: the owner name of - the next authoritative RRset in the canonical ordering of the zone, - and the set of RR types present at the NSEC RR's owner name. The - complete set of NSEC RRs in a zone both indicate which authoritative - RRsets exist in a zone and also form a chain of authoritative owner - names in the zone. This information is used to provide authenticated - denial of existence for DNS data, as described in - [I-D.ietf-dnsext-dnssec-protocol]. - - Because every authoritative name in a zone must be part of the NSEC - chain, NSEC RRs must be present for names containing a CNAME RR. - This is a change to the traditional DNS specification [RFC1034] that - stated that if a CNAME is present for a name, it is the only type - allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist - for the same name as a CNAME resource record in a secure zone. - - The type value for the NSEC RR is 47. - - The NSEC RR is class independent. - - The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirt of negative caching [RFC2308]. - -4.1 NSEC RDATA Wire Format - - The RDATA of the NSEC RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Domain Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -4.1.1 The Next Domain Name Field - - The Next Domain Name field contains the owner name of the next - authoritative owner name in the canonical ordering of the zone; see - Section 6.1 for an explanation of canonical ordering. The value of - the Next Domain Name field in the last NSEC record in the zone is the - name of the zone apex (the owner name of the zone's SOA RR). - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. A receiver which receives an - - - -Arends, et al. Expires August 16, 2004 [Page 15] - -Internet-Draft DNSSEC Resource Records February 2004 - - - NSEC RR containing a compressed Next Domain Name field SHOULD - decompress the field value. - - Owner names of RRsets not authoritative for the given zone (such as - glue records) MUST NOT be listed in the Next Domain Name unless at - least one authoritative RRset exists at the same owner name. - -4.1.2 The Type Bit Maps Field - - The Type Bit Maps field identifies the RRset types which exist at the - NSEC RR's owner name. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that has - at least one active RR type is encoded using a single octet window - number (from 0 to 255), a single octet bitmap length (from 1 to 32) - indicating the number of octets used for the window block's bitmap, - and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC RR RDATA in increasing numerical - order. - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - where "|" denotes concatenation. - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRset of that type is present for the NSEC - RR's owner name. If a bit is set to 0, it indicates that no RRset of - that type is present for the NSEC RR's owner name. - - Since bit 0 in window block 0 refers to the non-existent RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing pseudo-types MUST be set to 0, since they do not - appear in zone data. If encountered, they MUST be ignored upon - reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC RR's owner name. Trailing zero octets not specified MUST be - - - -Arends, et al. Expires August 16, 2004 [Page 16] - -Internet-Draft DNSSEC Resource Records February 2004 - - - interpreted as zero octets. - - A zone MUST NOT generate an NSEC RR for any domain name that only - holds glue records. - -4.1.3 Inclusion of Wildcard Names in NSEC RDATA - - If a wildcard owner name appears in a zone, the wildcard label ("*") - is treated as a literal symbol and is treated the same as any other - owner name for purposes of generating NSEC RRs. Wildcard owner names - appear in the Next Domain Name field without any wildcard expansion. - [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards - on authenticated denial of existence. - -4.2 The NSEC RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - The Type Bit Maps field is represented as a sequence of RR type - mnemonics. When the mnemonic is not known, the TYPE representation - as described in [RFC3597] (section 5) MUST be used. - -4.3 NSEC RR Example - - The following NSEC RR identifies the RRsets associated with - alfa.example.com. and identifies the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NSEC host.example.com. ( - A MX RRSIG NSEC TYPE1234 ) - - The first four text fields specify the name, TTL, Class, and RR type - (NSEC). The entry host.example.com. is the next authoritative name - after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, - and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and - TYPE1234 RRsets associated with the name alfa.example.com. - - The RDATA section of the NSEC RR above would be encoded as: - - 0x04 'h' 'o' 's' 't' - 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' - 0x03 'c' 'o' 'm' 0x00 - 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 - 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - - - -Arends, et al. Expires August 16, 2004 [Page 17] - -Internet-Draft DNSSEC Resource Records February 2004 - - - 0x00 0x00 0x00 0x00 0x20 - - Assuming that the resolver can authenticate this NSEC record, it - could be used to prove that beta.example.com does not exist, or could - be used to prove there is no AAAA record associated with - alfa.example.com. Authenticated denial of existence is discussed in - [I-D.ietf-dnsext-dnssec-protocol]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 18] - -Internet-Draft DNSSEC Resource Records February 2004 - - -5. The DS Resource Record - - The DS Resource Record refers to a DNSKEY RR and is used in the DNS - DNSKEY authentication process. A DS RR refers to a DNSKEY RR by - storing the key tag, algorithm number, and a digest of the DNSKEY RR. - Note that while the digest should be sufficient to identify the - public key, storing the key tag and key algorithm helps make the - identification process more efficient. By authenticating the DS - record, a resolver can authenticate the DNSKEY RR to which the DS - record points. The key authentication process is described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The DS RR and its corresponding DNSKEY RR have the same owner name, - but they are stored in different locations. The DS RR appears only - on the upper (parental) side of a delegation, and is authoritative - data in the parent zone. For example, the DS RR for "example.com" is - stored in the "com" zone (the parent zone) rather than in the - "example.com" zone (the child zone). The corresponding DNSKEY RR is - stored in the "example.com" zone (the child zone). This simplifies - DNS zone management and zone signing, but introduces special response - processing requirements for the DS RR; these are described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The type number for the DS record is 43. - - The DS resource record is class independent. - - The DS RR has no special TTL requirements. - -5.1 DS RDATA Wire Format - - The RDATA for a DS RR consists of a 2 octet Key Tag field, a one - octet Algorithm field, a one octet Digest Type field, and a Digest - field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | Digest Type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 19] - -Internet-Draft DNSSEC Resource Records February 2004 - - -5.1.1 The Key Tag Field - - The Key Tag field lists the key tag of the DNSKEY RR referred to by - the DS record. - - The Key Tag used by the DS RR is identical to the Key Tag used by - RRSIG RRs. Appendix B describes how to compute a Key Tag. - -5.1.2 The Algorithm Field - - The Algorithm field lists the algorithm number of the DNSKEY RR - referred to by the DS record. - - The algorithm number used by the DS RR is identical to the algorithm - number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm - number types. - -5.1.3 The Digest Type Field - - The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY - RR. The Digest Type field identifies the algorithm used to construct - the digest. Appendix A.2 lists the possible digest algorithm types. - -5.1.4 The Digest Field - - The DS record refers to a DNSKEY RR by including a digest of that - DNSKEY RR. - - The digest is calculated by concatenating the canonical form of the - fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, - and then applying the digest algorithm. - - digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); - - "|" denotes concatenation - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. - - - The size of the digest may vary depending on the digest algorithm and - DNSKEY RR size. As of the time of writing, the only defined digest - algorithm is SHA-1, which produces a 20 octet digest. - -5.2 Processing of DS RRs When Validating Responses - - The DS RR links the authentication chain across zone boundaries, so - the DS RR requires extra care in processing. The DNSKEY RR referred - to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST - - - -Arends, et al. Expires August 16, 2004 [Page 20] - -Internet-Draft DNSSEC Resource Records February 2004 - - - have Flags bit 7 set to value 1. If the key tag does not indicate a - DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT be - used in the validation process. - -5.3 The DS RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic specified in Appendix A.1. - - The Digest Type field MUST be represented as an unsigned decimal - integer. - - The Digest MUST be represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is allowed within the hexadecimal - text. - -5.4 DS RR Example - - The following example shows a DNSKEY RR and its corresponding DS RR. - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A - 98631FAD1A292118 ) - - - The first four text fields specify the name, TTL, Class, and RR type - (DS). Value 60485 is the key tag for the corresponding - "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm - used by this "dskey.example.com." DNSKEY RR. The value 1 is the - algorithm used to construct the digest, and the rest of the RDATA - text is the digest in hexadecimal. - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 21] - -Internet-Draft DNSSEC Resource Records February 2004 - - -6. Canonical Form and Order of Resource Records - - This section defines a canonical form for resource records, a - canonical ordering of DNS names, and a canonical ordering of resource - records within an RRset. A canonical name order is required to - construct the NSEC name chain. A canonical RR form and ordering - within an RRset are required to construct and verify RRSIG RRs. - -6.1 Canonical DNS Name Order - - For purposes of DNS security, owner names are ordered by treating - individual labels as unsigned left-justified octet strings. The - absence of a octet sorts before a zero value octet, and upper case - US-ASCII letters are treated as if they were lower case US-ASCII - letters. - - To compute the canonical ordering of a set of DNS names, start by - sorting the names according to their most significant (rightmost) - labels. For names in which the most significant label is identical, - continue sorting according to their next most significant label, and - so forth. - - For example, the following names are sorted in canonical DNS name - order. The most significant label is "example". At this level, - "example" sorts first, followed by names ending in "a.example", then - names ending "z.example". The names within each level are sorted in - the same way. - - example - a.example - yljkjljk.a.example - Z.a.example - zABC.a.EXAMPLE - z.example - \001.z.example - *.z.example - \200.z.example - - -6.2 Canonical RR Form - - For purposes of DNS security, the canonical form of an RR is the wire - format of the RR where: - - 1. Every domain name in the RR is fully expanded (no DNS name - compression) and fully qualified; - - 2. All uppercase US-ASCII letters in the owner name of the RR are - - - -Arends, et al. Expires August 16, 2004 [Page 22] - -Internet-Draft DNSSEC Resource Records February 2004 - - - replaced by the corresponding lowercase US-ASCII letters; - - 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, - HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, - SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in - the DNS names contained within the RDATA are replaced by the - corresponding lowercase US-ASCII letters; - - 4. If the owner name of the RR is a wildcard name, the owner name is - in its original unexpanded form, including the "*" label (no - wildcard substitution); and - - 5. The RR's TTL is set to its original value as it appears in the - originating authoritative zone or the Original TTL field of the - covering RRSIG RR. - - -6.3 Canonical RR Ordering Within An RRset - - For purposes of DNS security, RRs with the same owner name, class, - and type are sorted by treating the RDATA portion of the canonical - form of each RR as a left-justified unsigned octet sequence where the - absence of an octet sorts before a zero octet. - - [RFC2181] specifies that an RRset is not allowed to contain duplicate - records (multiple RRs with the same owner name, class, type, and - RDATA). Therefore, if an implementation detects duplicate RRs during - RRset canonicalization, the implementation MUST treat this as a - protocol error. If the implementation chooses to handle this - protocol error in the spirit of the robustness principle (being - liberal in what it accepts), the implementation MUST remove all but - one of the duplicate RR(s) for purposes of calculating the canonical - form of the RRset. - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 23] - -Internet-Draft DNSSEC Resource Records February 2004 - - -7. IANA Considerations - - This document introduces no new IANA considerations, because all of - the protocol parameters used in this document have already been - assigned by previous specifications. However, since the evolution of - DNSSEC has been long and somewhat convoluted, this section attempts - to describe the current state of the IANA registries and other - protocol parameters which are (or once were) related to DNSSEC. - - Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA - considerations. - - DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to - the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS - Resource Record Type 43 to DS. - [I-D.ietf-dnsext-dnssec-2535typecode-change] assigned types 46, - 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. - [I-D.ietf-dnsext-dnssec-2535typecode-change] also marked type 30 - (NXT) as Obsolete, and restricted use of types 24 (SIG) and 25 - (KEY) to the "SIG(0)" transaction security protocol described in - [RFC2931] and the transaction KEY Resource Record described in - [RFC2930]. - - DNS Security Algorithm Numbers: [RFC2535] created an IANA registry - for DNSSEC Resource Record Algorithm field numbers, and assigned - values 1-4 and 252-255. [RFC3110] assigned value 5. - [I-D.ietf-dnsext-dnssec-2535typecode-change] altered this registry - to include flags for each entry regarding its use with the DNS - security extensions. Each algorithm entry could refer to an - algorithm that can be used for zone signing, transaction security - (see [RFC2931]) or both. Values 6-251 are available for assignment - by IETF standards action. See Appendix A for a full listing of the - DNS Security Algorithm Numbers entries at the time of writing and - their status of use in DNSSEC. - - [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and - assigned value 0 to reserved and value 1 to SHA-1. - - KEY Protocol Values: [RFC2535] created an IANA Registry for KEY - Protocol Values, but [RFC3445] re-assigned all assigned values - other than 3 to reserved and closed this IANA registry. The - registry remains closed, and all KEY and DNSKEY records are - required to have Protocol Octet value of 3. - - Flag bits in the KEY and DNSKEY RRs: - [I-D.ietf-dnsext-dnssec-2535typecode-change] created an IANA - registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, - this registry only contains an assignment for bit 7 (the ZONE bit) - - - -Arends, et al. Expires August 16, 2004 [Page 24] - -Internet-Draft DNSSEC Resource Records February 2004 - - - and a reservation for bit 15 for the Secure Entry Point flag (SEP - bit) [I-D.ietf-dnsext-keyrr-key-signing-flag]. Bits 0-6 and 8-14 - are available for assignment by IETF Standards Action. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 25] - -Internet-Draft DNSSEC Resource Records February 2004 - - -8. Security Considerations - - This document describes the format of four DNS resource records used - by the DNS security extensions, and presents an algorithm for - calculating a key tag for a public key. Other than the items - described below, the resource records themselves introduce no - security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] - and [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations related to the use of these records. - - The DS record points to a DNSKEY RR using a cryptographic digest, the - key algorithm type and a key tag. The DS record is intended to - identify an existing DNSKEY RR, but it is theoretically possible for - an attacker to generate a DNSKEY that matches all the DS fields. The - probability of constructing such a matching DNSKEY depends on the - type of digest algorithm in use. The only currently defined digest - algorithm is SHA-1, and the working group believes that constructing - a public key which would match the algorithm, key tag, and SHA-1 - digest given in a DS record would be a sufficiently difficult problem - that such an attack is not a serious threat at this time. - - The key tag is used to help select DNSKEY resource records - efficiently, but it does not uniquely identify a single DNSKEY - resource record. It is possible for two distinct DNSKEY RRs to have - the same owner name, the same algorithm type, and the same key tag. - An implementation which used only the key tag to select a DNSKEY RR - might select the wrong public key in some circumstances. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 26] - -Internet-Draft DNSSEC Resource Records February 2004 - - -9. Acknowledgments - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 27] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet - Mail Extensions) Part One: Mechanisms for Specifying and - Describing the Format of Internet Message Bodies", RFC - 1521, September 1993. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [I-D.ietf-dnsext-dnssec-intro] - - - -Arends, et al. Expires August 16, 2004 [Page 28] - -Internet-Draft DNSSEC Resource Records February 2004 - - - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-09 (work in progress), - February 2004. - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in - progress), February 2004. - - [I-D.ietf-dnsext-keyrr-key-signing-flag] - Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", - draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in - progress), December 2003. - - [I-D.ietf-dnsext-dnssec-2535typecode-change] - Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06 - (work in progress), December 2003. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 29] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Informative References - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - - - - -Arends, et al. Expires August 16, 2004 [Page 30] - -Internet-Draft DNSSEC Resource Records February 2004 - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 31] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Appendix A. DNSSEC Algorithm and Digest Types - - The DNS security extensions are designed to be independent of the - underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS - resource records all use a DNSSEC Algorithm Number to identify the - cryptographic algorithm in use by the resource record. The DS - resource record also specifies a Digest Algorithm Number to identify - the digest algorithm used to construct the DS record. The currently - defined Algorithm and Digest Types are listed below. Additional - Algorithm or Digest Types could be added as advances in cryptography - warrant. - - A DNSSEC aware resolver or name server MUST implement all MANDATORY - algorithms. - -A.1 DNSSEC Algorithm Types - - The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify - the security algorithm being used. These values are stored in the - "Algorithm number" field in the resource record RDATA. - - Some algorithms are usable only for zone signing (DNSSEC), some only - for transaction security mechanisms (SIG(0) and TSIG), and some for - both. Those usable for zone signing may appear in DNSKEY, RRSIG, and - DS RRs. Those usable for transaction security would be present in - SIG(0) and KEY RRs as described in [RFC2931] - - Zone - Value Algorithm [Mnemonic] Signing References Status - ----- -------------------- --------- ---------- --------- - 0 reserved - 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED - 2 Diffie-Hellman [DH] n RFC 2539 - - 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL - 4 Elliptic Curve [ECC] TBA - - 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY - 252 Indirect [INDIRECT] n - - 253 Private [PRIVATEDNS] y see below OPTIONAL - 254 Private [PRIVATEOID] y see below OPTIONAL - 255 reserved - - 6 - 251 Available for assignment by IETF Standards Action. - -A.1.1 Private Algorithm Types - - Algorithm number 253 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with a wire encoded - - - -Arends, et al. Expires August 16, 2004 [Page 32] - -Internet-Draft DNSSEC Resource Records February 2004 - - - domain name, which MUST NOT be compressed. The domain name indicates - the private algorithm to use and the remainder of the public key area - is determined by that algorithm. Entities should only use domain - names they control to designate their private algorithms. - - Algorithm number 254 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with an unsigned - length byte followed by a BER encoded Object Identifier (ISO OID) of - that length. The OID indicates the private algorithm in use and the - remainder of the area is whatever is required by that algorithm. - Entities should only use OIDs they control to designate their private - algorithms. - -A.2 DNSSEC Digest Types - - A "Digest Type" field in the DS resource record types identifies the - cryptographic digest algorithm used by the resource record. The - following table lists the currently defined digest algorithm types. - - VALUE Algorithm STATUS - 0 Reserved - - 1 SHA-1 MANDATORY - 2-255 Unassigned - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 33] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Appendix B. Key Tag Calculation - - The Key Tag field in the RRSIG and DS resource record types provides - a mechanism for selecting a public key efficiently. In most cases, a - combination of owner name, algorithm, and key tag can efficiently - identify a DNSKEY record. Both the RRSIG and DS resource records - have corresponding DNSKEY records. The Key Tag field in the RRSIG - and DS records can be used to help select the corresponding DNSKEY RR - efficiently when more than one candidate DNSKEY RR is available. - - However, it is essential to note that the key tag is not a unique - identifier. It is theoretically possible for two distinct DNSKEY RRs - to have the same owner name, the same algorithm, and the same key - tag. The key tag is used to limit the possible candidate keys, but it - does not uniquely identify a DNSKEY record. Implementations MUST NOT - assume that the key tag uniquely identifies a DNSKEY RR. - - The key tag is the same for all DNSKEY algorithm types except - algorithm 1 (please see Appendix B.1 for the definition of the key - tag for algorithm 1). The key tag algorithm is the sum of the wire - format of the DNSKEY RDATA broken into 2 octet groups. First the - RDATA (in wire format) is treated as a series of 2 octet groups, - these groups are then added together ignoring any carry bits. A - reference implementation of the key tag algorithm is as an ANSI C - function is given below with the RDATA portion of the DNSKEY RR is - used as input. It is not necessary to use the following reference - code verbatim, but the numerical value of the Key Tag MUST be - identical to what the reference implementation would generate for the - same input. - - Please note that the algorithm for calculating the Key Tag is almost - but not completely identical to the familiar ones complement checksum - used in many other Internet protocols. Key Tags MUST be calculated - using the algorithm described here rather than the ones complement - checksum. - - The following ANSI C reference implementation calculates the value of - a Key Tag. This reference implementation applies to all algorithm - types except algorithm 1 (see Appendix B.1). The input is the wire - format of the RDATA portion of the DNSKEY RR. The code is written - for clarity, not efficiency. - - /* - * Assumes that int is at least 16 bits. - * First octet of the key tag is the most significant 8 bits of the - * return value; - * Second octet of the key tag is the least significant 8 bits of the - * return value. - - - -Arends, et al. Expires August 16, 2004 [Page 34] - -Internet-Draft DNSSEC Resource Records February 2004 - - - */ - - unsigned int - keytag ( - unsigned char key[], /* the RDATA part of the DNSKEY RR */ - unsigned int keysize /* the RDLENGTH */ - ) - { - unsigned long ac; /* assumed to be 32 bits or larger */ - int i; /* loop index */ - - for ( ac = 0, i = 0; i < keysize; ++i ) - ac += (i & 1) ? key[i] : key[i] << 8; - ac += (ac >> 16) & 0xFFFF; - return ac & 0xFFFF; - } - - -B.1 Key Tag for Algorithm 1 (RSA/MD5) - - The key tag for algorithm 1 (RSA/MD5) is defined differently than the - key tag for all other algorithms, for historical reasons. For a - DNSKEY RR with algorithm 1, the key tag is defined to be the most - significant 16 bits of the least significant 24 bits in the public - key modulus (in other words, the 4th to last and 3rd to last octets - of the public key modulus). - - Please note that Algorithm 1 is NOT RECOMMENDED. - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 35] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires August 16, 2004 [Page 36] - -Internet-Draft DNSSEC Resource Records February 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 37] - - +
+
+DNS Extensions R. Arends
+Internet-Draft Telematica Instituut
+Expires: November 15, 2004 R. Austein
+ ISC
+ M. Larson
+ VeriSign
+ D. Massey
+ USC/ISI
+ S. Rose
+ NIST
+ May 17, 2004
+
+
+ Resource Records for the DNS Security Extensions
+ draft-ietf-dnsext-dnssec-records-08
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on November 15, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document is part of a family of documents that describes the DNS
+ Security Extensions (DNSSEC). The DNS Security Extensions are a
+ collection of resource records and protocol modifications that
+ provide source authentication for the DNS. This document defines the
+ public key (DNSKEY), delegation signer (DS), resource record digital
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 1]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ signature (RRSIG), and authenticated denial of existence (NSEC)
+ resource records. The purpose and format of each resource record is
+ described in detail, and an example of each resource record is given.
+
+ This document obsoletes RFC 2535 and incorporates changes from all
+ updates to RFC 2535.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1 Background and Related Documents . . . . . . . . . . . . . 4
+ 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3.1 Technical Changes or Corrections . . . . . . . . . . . 4
+ 1.3.2 Typos and Minor Corrections . . . . . . . . . . . . . 5
+ 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 6
+ 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 6
+ 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 6
+ 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 7
+ 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 7
+ 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 7
+ 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 7
+ 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 7
+ 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 8
+ 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 9
+ 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 9
+ 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 10
+ 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 10
+ 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 10
+ 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 11
+ 3.1.5 Signature Expiration and Inception Fields . . . . . . 11
+ 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 11
+ 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 12
+ 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 12
+ 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 13
+ 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13
+ 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 15
+ 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 15
+ 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 15
+ 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 16
+ 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 17
+ 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 17
+ 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 17
+ 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 19
+ 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 19
+ 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 20
+ 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 20
+ 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 20
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 2]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 20
+ 5.2 Processing of DS RRs When Validating Responses . . . . . . 20
+ 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 21
+ 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 21
+ 6. Canonical Form and Order of Resource Records . . . . . . . . . 22
+ 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 22
+ 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 22
+ 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 23
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
+ 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 27
+ 10.2 Informative References . . . . . . . . . . . . . . . . . . . 28
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
+ A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 30
+ A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 30
+ A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 30
+ A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 31
+ B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 32
+ B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 33
+ Intellectual Property and Copyright Statements . . . . . . . . 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 3]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+1. Introduction
+
+ The DNS Security Extensions (DNSSEC) introduce four new DNS resource
+ record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the
+ purpose of each resource record (RR), the RR's RDATA format, and its
+ presentation format (ASCII representation).
+
+1.1 Background and Related Documents
+
+ The reader is assumed to be familiar with the basic DNS concepts
+ described in [RFC1034], [RFC1035] and subsequent RFCs that update
+ them: [RFC2136], [RFC2181] and [RFC2308].
+
+ This document is part of a family of documents that define the DNS
+ security extensions. The DNS security extensions (DNSSEC) are a
+ collection of resource records and DNS protocol modifications that
+ add source authentication and data integrity to the Domain Name
+ System (DNS). An introduction to DNSSEC and definitions of common
+ terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description
+ of DNS protocol modifications can be found in
+ [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC
+ resource records.
+
+1.2 Reserved Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.3 Editors' Notes
+
+1.3.1 Technical Changes or Corrections
+
+ Please report technical corrections to dnssec-editors@east.isi.edu.
+ To assist the editors, please indicate the text in error and point
+ out the RFC that defines the correct behavior. For a technical
+ change where no RFC that defines the correct behavior, or if there's
+ more than one applicable RFC and the definitions conflict, please
+ post the issue to namedroppers.
+
+ An example correction to dnssec-editors might be: Page X says
+ "DNSSEC RRs SHOULD be automatically returned in responses." This was
+ true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
+ DNSSEC RR types MUST NOT be included in responses unless the resolver
+ indicated support for DNSSEC.
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 4]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+1.3.2 Typos and Minor Corrections
+
+ Please report any typos corrections to dnssec-editors@east.isi.edu.
+ To assist the editors, please provide enough context for us to find
+ the incorrect text quickly.
+
+ An example message to dnssec-editors might be: page X says "the
+ DNSSEC standard has been in development for over 1 years". It
+ should read "over 10 years".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 5]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+2. The DNSKEY Resource Record
+
+ DNSSEC uses public key cryptography to sign and authenticate DNS
+ resource record sets (RRsets). The public keys are stored in DNSKEY
+ resource records and are used in the DNSSEC authentication process
+ described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its
+ authoritative RRsets using a private key and stores the corresponding
+ public key in a DNSKEY RR. A resolver can then use the public key to
+ authenticate signatures covering the RRsets in the zone.
+
+ The DNSKEY RR is not intended as a record for storing arbitrary
+ public keys and MUST NOT be used to store certificates or public keys
+ that do not directly relate to the DNS infrastructure.
+
+ The Type value for the DNSKEY RR type is 48.
+
+ The DNSKEY RR is class independent.
+
+ The DNSKEY RR has no special TTL requirements.
+
+2.1 DNSKEY RDATA Wire Format
+
+ The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
+ octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
+ Field.
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags | Protocol | Algorithm |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / /
+ / Public Key /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+2.1.1 The Flags Field
+
+ Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
+ then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner
+ name MUST be the name of a zone. If bit 7 has value 0, then the
+ DNSKEY record holds some other type of DNS public key, such as a
+ public key used by TKEY and MUST NOT be used to verify RRSIGs that
+ cover RRsets.
+
+ Bit 15 of the Flags field is the Secure Entry Point flag, described
+ in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 6]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ key intended for use as a secure entry point. This flag is only
+ intended to be to a hint to zone signing or debugging software as to
+ the intended use of this DNSKEY record; validators MUST NOT alter
+ their behavior during the signature validation process in any way
+ based on the setting of this bit. This also means a DNSKEY RR with
+ the SEP bit set would also need the Zone Key flag set in order to
+ legally be able to generate signatures. A DNSKEY RR with the SEP set
+ and the Zone Key flag not set is an invalid DNSKEY.
+
+ Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
+ creation of the DNSKEY RR, and MUST be ignored upon reception.
+
+2.1.2 The Protocol Field
+
+ The Protocol Field MUST have value 3 and the DNSKEY RR MUST be
+ treated as invalid during signature verification if found to be some
+ value other than 3.
+
+2.1.3 The Algorithm Field
+
+ The Algorithm field identifies the public key's cryptographic
+ algorithm and determines the format of the Public Key field. A list
+ of DNSSEC algorithm types can be found in Appendix A.1
+
+2.1.4 The Public Key Field
+
+ The Public Key Field holds the public key material. The format
+ depends on the algorithm of the key being stored and are described in
+ separate documents.
+
+2.1.5 Notes on DNSKEY RDATA Design
+
+ Although the Protocol Field always has value 3, it is retained for
+ backward compatibility with early versions of the KEY record.
+
+2.2 The DNSKEY RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Flag field MUST be represented as an unsigned decimal integer
+ with a value of 0, 256, or 257.
+
+ The Protocol Field MUST be represented as an unsigned decimal integer
+ with a value of 3.
+
+ The Algorithm field MUST be represented either as an unsigned decimal
+ integer or as an algorithm mnemonic as specified in Appendix A.1.
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 7]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ The Public Key field MUST be represented as a Base64 encoding of the
+ Public Key. Whitespace is allowed within the Base64 text. For a
+ definition of Base64 encoding, see [RFC1521] Section 5.2.
+
+2.3 DNSKEY RR Example
+
+ The following DNSKEY RR stores a DNS zone key for example.com.
+
+ example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
+ Cbl+BBZH4b/0PY1kxkmvHjcZc8no
+ kfzj31GajIQKY+5CptLr3buXA10h
+ WqTkF7H6RfoRqXQeogmMHfpftf6z
+ Mv1LyBUgia7za6ZEzOJBOztyvhjL
+ 742iU/TpPSEDhm2SNKLijfUppn1U
+ aNvv4w== )
+
+ The first four text fields specify the owner name, TTL, Class, and RR
+ type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in
+ the Flags field has value 1. Value 3 is the fixed Protocol value.
+ Value 5 indicates the public key algorithm. Appendix A.1 identifies
+ algorithm type 5 as RSA/SHA1 and indicates that the format of the
+ RSA/SHA1 public key field is defined in [RFC3110]. The remaining
+ text is a Base64 encoding of the public key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 8]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+3. The RRSIG Resource Record
+
+ DNSSEC uses public key cryptography to sign and authenticate DNS
+ resource record sets (RRsets). Digital signatures are stored in
+ RRSIG resource records and are used in the DNSSEC authentication
+ process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator
+ can use these RRSIG RRs to authenticate RRsets from the zone. The
+ RRSIG RR MUST only be used to carry verification material (digital
+ signatures) used to secure DNS operations.
+
+ An RRSIG record contains the signature for an RRset with a particular
+ name, class, and type. The RRSIG RR specifies a validity interval
+ for the signature and uses the Algorithm, the Signer's Name, and the
+ Key Tag to identify the DNSKEY RR containing the public key that a
+ validator can use to verify the signature.
+
+ Because every authoritative RRset in a zone must be protected by a
+ digital signature, RRSIG RRs must be present for names containing a
+ CNAME RR. This is a change to the traditional DNS specification
+ [RFC1034] that stated that if a CNAME is present for a name, it is
+ the only type allowed at that name. A RRSIG and NSEC (see Section 4)
+ MUST exist for the same name as a CNAME resource record in a signed
+ zone.
+
+ The Type value for the RRSIG RR type is 46.
+
+ The RRSIG RR is class independent.
+
+ An RRSIG RR MUST have the same class as the RRset it covers.
+
+ The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset
+ it covers. This is an exception to the [RFC2181] rules for TTL
+ values of individual RRs within a RRset: individual RRSIG with the
+ same owner name will have different TTL values if the RRsets they
+ cover have different TTL values.
+
+3.1 RRSIG RDATA Wire Format
+
+ The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
+ 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
+ TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
+ Inception field, a 2 octet Key tag, the Signer's Name field, and the
+ Signature field.
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 9]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type Covered | Algorithm | Labels |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Original TTL |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Signature Expiration |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Signature Inception |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Tag | /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / /
+ / Signature /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+3.1.1 The Type Covered Field
+
+ The Type Covered field identifies the type of the RRset that is
+ covered by this RRSIG record.
+
+3.1.2 The Algorithm Number Field
+
+ The Algorithm Number field identifies the cryptographic algorithm
+ used to create the signature. A list of DNSSEC algorithm types can
+ be found in Appendix A.1
+
+3.1.3 The Labels Field
+
+ The Labels field specifies the number of labels in the original RRSIG
+ RR owner name. The significance of this field is that a validator
+ uses it to determine if the answer was synthesized from a wildcard.
+ If so, it can be used to determine what owner name was used in
+ generating the signature.
+
+ To validate a signature, the validator needs the original owner name
+ that was used to create the signature. If the original owner name
+ contains a wildcard label ("*"), the owner name may have been
+ expanded by the server during the response process, in which case the
+ validator will need to reconstruct the original owner name in order
+ to validate the signature. [I-D.ietf-dnsext-dnssec-protocol]
+ describes how to use the Labels field to reconstruct the original
+ owner name.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 10]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ The value of the Labels field MUST NOT count either the null (root)
+ label that terminates the owner name or the wildcard label (if
+ present). The value of the Labels field MUST be less than or equal
+ to the number of labels in the RRSIG owner name. For example,
+ "www.example.com." has a Labels field value of 3, and
+ "*.example.com." has a Labels field value of 2. Root (".") has a
+ Labels field value of 0.
+
+ Although the wildcard label is not included in the count stored in
+ the Labels field of the RRSIG RR, the wildcard label is part of the
+ RRset's owner name when generating or verifying the signature.
+
+3.1.4 Original TTL Field
+
+ The Original TTL field specifies the TTL of the covered RRset as it
+ appears in the authoritative zone.
+
+ The Original TTL field is necessary because a caching resolver
+ decrements the TTL value of a cached RRset. In order to validate a
+ signature, a validator requires the original TTL.
+ [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original
+ TTL field value to reconstruct the original TTL.
+
+3.1.5 Signature Expiration and Inception Fields
+
+ The Signature Expiration and Inception fields specify a validity
+ period for the signature. The RRSIG record MUST NOT be used for
+ authentication prior to the inception date and MUST NOT be used for
+ authentication after the expiration date.
+
+ Signature Expiration and Inception field values are in POSIX.1 time
+ format: a 32-bit unsigned number of seconds elapsed since 1 January
+ 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The
+ longest interval which can be expressed by this format without
+ wrapping is approximately 136 years. An RRSIG RR can have an
+ Expiration field value which is numerically smaller than the
+ Inception field value if the expiration field value is near the
+ 32-bit wrap-around point or if the signature is long lived. Because
+ of this, all comparisons involving these fields MUST use "Serial
+ number arithmetic" as defined in [RFC1982]. As a direct consequence,
+ the values contained in these fields cannot refer to dates more than
+ 68 years in either the past or the future.
+
+3.1.6 The Key Tag Field
+
+ The Key Tag field contains the key tag value of the DNSKEY RR that
+ validates this signature. Appendix B explains how to calculate Key
+ Tag values.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 11]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+3.1.7 The Signer's Name Field
+
+ The Signer's Name field value identifies the owner name of the DNSKEY
+ RR which a validator should use to validate this signature. The
+ Signer's Name field MUST contain the name of the zone of the covered
+ RRset. A sender MUST NOT use DNS name compression on the Signer's
+ Name field when transmitting a RRSIG RR.
+
+3.1.8 The Signature Field
+
+ The Signature field contains the cryptographic signature that covers
+ the RRSIG RDATA (excluding the Signature field) and the RRset
+ specified by the RRSIG owner name, RRSIG class, and RRSIG Type
+ Covered field. The format of this field depends on the algorithm in
+ use and these formats are described in separate companion documents.
+
+3.1.8.1 Signature Calculation
+
+ A signature covers the RRSIG RDATA (excluding the Signature Field)
+ and covers the data RRset specified by the RRSIG owner name, RRSIG
+ class, and RRSIG Type Covered fields. The RRset is in canonical form
+ (see Section 6) and the set RR(1),...RR(n) is signed as follows:
+
+ signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
+
+ "|" denotes concatenation;
+
+ RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+ with the Signer's Name field in canonical form and
+ the Signature field excluded;
+
+ RR(i) = owner | type | class | TTL | RDATA length | RDATA
+
+ "owner" is the fully qualified owner name of the RRset in
+ canonical form (for RRs with wildcard owner names, the
+ wildcard label is included in the owner name);
+
+ Each RR MUST have the same owner name as the RRSIG RR;
+
+ Each RR MUST have the same class as the RRSIG RR;
+
+ Each RR in the RRset MUST have the RR type listed in the
+ RRSIG RR's Type Covered field;
+
+ Each RR in the RRset MUST have the TTL listed in the
+ RRSIG Original TTL Field;
+
+ Any DNS names in the RDATA field of each RR MUST be in
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 12]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ canonical form; and
+
+ The RRset MUST be sorted in canonical order.
+
+ See Section 6.1 and Section 6.2 for details on canonical name order
+ and canonical RR form.
+
+3.2 The RRSIG RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Type Covered field is represented as a RR type mnemonic. When
+ the mnemonic is not known, the TYPE representation as described in
+ [RFC3597] (section 5) MUST be used.
+
+ The Algorithm field value MUST be represented either as an unsigned
+ decimal integer or as an algorithm mnemonic as specified in Appendix
+ A.1.
+
+ The Labels field value MUST be represented as an unsigned decimal
+ integer.
+
+ The Original TTL field value MUST be represented as an unsigned
+ decimal integer.
+
+ The Signature Expiration Time and Inception Time field values MUST be
+ represented either as seconds since 1 January 1970 00:00:00 UTC or in
+ the form YYYYMMDDHHmmSS in UTC, where:
+ YYYY is the year (0000-9999, but see Section 3.1.5);
+ MM is the month number (01-12);
+ DD is the day of the month (01-31);
+ HH is the hour in 24 hours notation (00-23);
+ mm is the minute (00-59); and
+ SS is the second (00-59).
+
+ The Key Tag field MUST be represented as an unsigned decimal integer.
+
+ The Signer's Name field value MUST be represented as a domain name.
+
+ The Signature field is represented as a Base64 encoding of the
+ signature. Whitespace is allowed within the Base64 text. See
+ Section 2.2.
+
+3.3 RRSIG RR Example
+
+ The following RRSIG RR stores the signature for the A RRset of
+ host.example.com:
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 13]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
+ 20030220173103 2642 example.com.
+ oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
+ PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
+ B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
+ GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
+ J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
+
+ The first four fields specify the owner name, TTL, Class, and RR type
+ (RRSIG). The "A" represents the Type Covered field. The value 5
+ identifies the algorithm used (RSA/SHA1) to create the signature.
+ The value 3 is the number of Labels in the original owner name. The
+ value 86400 in the RRSIG RDATA is the Original TTL for the covered A
+ RRset. 20030322173103 and 20030220173103 are the expiration and
+ inception dates, respectively. 2642 is the Key Tag, and example.com.
+ is the Signer's Name. The remaining text is a Base64 encoding of the
+ signature.
+
+ Note that combination of RRSIG RR owner name, class, and Type Covered
+ indicate that this RRSIG covers the "host.example.com" A RRset. The
+ Label value of 3 indicates that no wildcard expansion was used. The
+ Algorithm, Signer's Name, and Key Tag indicate this signature can be
+ authenticated using an example.com zone DNSKEY RR whose algorithm is
+ 5 and key tag is 2642.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 14]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+4. The NSEC Resource Record
+
+ The NSEC resource record lists two separate things: the owner name of
+ the next authoritative RRset in the canonical ordering of the zone,
+ and the set of RR types present at the NSEC RR's owner name. The
+ complete set of NSEC RRs in a zone both indicate which authoritative
+ RRsets exist in a zone and also form a chain of authoritative owner
+ names in the zone. This information is used to provide authenticated
+ denial of existence for DNS data, as described in
+ [I-D.ietf-dnsext-dnssec-protocol].
+
+ Because every authoritative name in a zone must be part of the NSEC
+ chain, NSEC RRs must be present for names containing a CNAME RR.
+ This is a change to the traditional DNS specification [RFC1034] that
+ stated that if a CNAME is present for a name, it is the only type
+ allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist
+ for the same name as a CNAME resource record in a signed zone.
+
+ See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone
+ signer determines precisely which NSEC RRs it needs to include in a
+ zone.
+
+ The type value for the NSEC RR is 47.
+
+ The NSEC RR is class independent.
+
+ The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
+ field. This is in the spirit of negative caching [RFC2308].
+
+4.1 NSEC RDATA Wire Format
+
+ The RDATA of the NSEC RR is as shown below:
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Next Domain Name /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Type Bit Maps /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+4.1.1 The Next Domain Name Field
+
+ The Next Domain Name field contains the owner name of the next
+ authoritative owner name in the canonical ordering of the zone; see
+ Section 6.1 for an explanation of canonical ordering. The value of
+ the Next Domain Name field in the last NSEC record in the zone is the
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 15]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ name of the zone apex (the owner name of the zone's SOA RR).
+
+ A sender MUST NOT use DNS name compression on the Next Domain Name
+ field when transmitting an NSEC RR.
+
+ Owner names of RRsets not authoritative for the given zone (such as
+ glue records) MUST NOT be listed in the Next Domain Name unless at
+ least one authoritative RRset exists at the same owner name.
+
+4.1.2 The Type Bit Maps Field
+
+ The Type Bit Maps field identifies the RRset types which exist at the
+ NSEC RR's owner name.
+
+ The RR type space is split into 256 window blocks, each representing
+ the low-order 8 bits of the 16-bit RR type space. Each block that has
+ at least one active RR type is encoded using a single octet window
+ number (from 0 to 255), a single octet bitmap length (from 1 to 32)
+ indicating the number of octets used for the window block's bitmap,
+ and up to 32 octets (256 bits) of bitmap.
+
+ Blocks are present in the NSEC RR RDATA in increasing numerical
+ order.
+
+ Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+
+ where "|" denotes concatenation.
+
+ Each bitmap encodes the low-order 8 bits of RR types within the
+ window block, in network bit order. The first bit is bit 0. For
+ window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+ to RR type 2 (NS), and so forth. For window block 1, bit 1
+ corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
+ 1, it indicates that an RRset of that type is present for the NSEC
+ RR's owner name. If a bit is set to 0, it indicates that no RRset of
+ that type is present for the NSEC RR's owner name.
+
+ Bits representing pseudo-types MUST be set to 0, since they do not
+ appear in zone data. If encountered, they MUST be ignored upon
+ reading.
+
+ Blocks with no types present MUST NOT be included. Trailing zero
+ octets in the bitmap MUST be omitted. The length of each block's
+ bitmap is determined by the type code with the largest numerical
+ value, within that block, among the set of RR types present at the
+ NSEC RR's owner name. Trailing zero octets not specified MUST be
+ interpreted as zero octets.
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 16]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ The bitmap for the NSEC RR at a delegation point requires special
+ attention. Bits corresponding to the delegation NS RRset and the RR
+ types for which the parent zone has authoritative data MUST be set to
+ 1; bits corresponding to any non-NS RRset for which the parent is not
+ authoritative MUST be set to 0.
+
+ A zone MUST NOT include an NSEC RR for any domain name that only
+ holds glue records.
+
+4.1.3 Inclusion of Wildcard Names in NSEC RDATA
+
+ If a wildcard owner name appears in a zone, the wildcard label ("*")
+ is treated as a literal symbol and is treated the same as any other
+ owner name for purposes of generating NSEC RRs. Wildcard owner names
+ appear in the Next Domain Name field without any wildcard expansion.
+ [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards
+ on authenticated denial of existence.
+
+4.2 The NSEC RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Next Domain Name field is represented as a domain name.
+
+ The Type Bit Maps field is represented as a sequence of RR type
+ mnemonics. When the mnemonic is not known, the TYPE representation
+ as described in [RFC3597] (section 5) MUST be used.
+
+4.3 NSEC RR Example
+
+ The following NSEC RR identifies the RRsets associated with
+ alfa.example.com. and identifies the next authoritative name after
+ alfa.example.com.
+
+ alfa.example.com. 86400 IN NSEC host.example.com. (
+ A MX RRSIG NSEC TYPE1234 )
+
+ The first four text fields specify the name, TTL, Class, and RR type
+ (NSEC). The entry host.example.com. is the next authoritative name
+ after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC,
+ and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
+ TYPE1234 RRsets associated with the name alfa.example.com.
+
+ The RDATA section of the NSEC RR above would be encoded as:
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 17]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ 0x04 'h' 'o' 's' 't'
+ 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
+ 0x03 'c' 'o' 'm' 0x00
+ 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
+ 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x20
+
+ Assuming that the validator can authenticate this NSEC record, it
+ could be used to prove that beta.example.com does not exist, or could
+ be used to prove there is no AAAA record associated with
+ alfa.example.com. Authenticated denial of existence is discussed in
+ [I-D.ietf-dnsext-dnssec-protocol].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 18]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+5. The DS Resource Record
+
+ The DS Resource Record refers to a DNSKEY RR and is used in the DNS
+ DNSKEY authentication process. A DS RR refers to a DNSKEY RR by
+ storing the key tag, algorithm number, and a digest of the DNSKEY RR.
+ Note that while the digest should be sufficient to identify the
+ public key, storing the key tag and key algorithm helps make the
+ identification process more efficient. By authenticating the DS
+ record, a resolver can authenticate the DNSKEY RR to which the DS
+ record points. The key authentication process is described in
+ [I-D.ietf-dnsext-dnssec-protocol].
+
+ The DS RR and its corresponding DNSKEY RR have the same owner name,
+ but they are stored in different locations. The DS RR appears only
+ on the upper (parental) side of a delegation, and is authoritative
+ data in the parent zone. For example, the DS RR for "example.com" is
+ stored in the "com" zone (the parent zone) rather than in the
+ "example.com" zone (the child zone). The corresponding DNSKEY RR is
+ stored in the "example.com" zone (the child zone). This simplifies
+ DNS zone management and zone signing, but introduces special response
+ processing requirements for the DS RR; these are described in
+ [I-D.ietf-dnsext-dnssec-protocol].
+
+ The type number for the DS record is 43.
+
+ The DS resource record is class independent.
+
+ The DS RR has no special TTL requirements.
+
+5.1 DS RDATA Wire Format
+
+ The RDATA for a DS RR consists of a 2 octet Key Tag field, a one
+ octet Algorithm field, a one octet Digest Type field, and a Digest
+ field.
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Tag | Algorithm | Digest Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / /
+ / Digest /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 19]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+5.1.1 The Key Tag Field
+
+ The Key Tag field lists the key tag of the DNSKEY RR referred to by
+ the DS record.
+
+ The Key Tag used by the DS RR is identical to the Key Tag used by
+ RRSIG RRs. Appendix B describes how to compute a Key Tag.
+
+5.1.2 The Algorithm Field
+
+ The Algorithm field lists the algorithm number of the DNSKEY RR
+ referred to by the DS record.
+
+ The algorithm number used by the DS RR is identical to the algorithm
+ number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm
+ number types.
+
+5.1.3 The Digest Type Field
+
+ The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
+ RR. The Digest Type field identifies the algorithm used to construct
+ the digest. Appendix A.2 lists the possible digest algorithm types.
+
+5.1.4 The Digest Field
+
+ The DS record refers to a DNSKEY RR by including a digest of that
+ DNSKEY RR.
+
+ The digest is calculated by concatenating the canonical form of the
+ fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
+ and then applying the digest algorithm.
+
+ digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
+
+ "|" denotes concatenation
+
+ DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
+
+
+ The size of the digest may vary depending on the digest algorithm and
+ DNSKEY RR size. As of the time of writing, the only defined digest
+ algorithm is SHA-1, which produces a 20 octet digest.
+
+5.2 Processing of DS RRs When Validating Responses
+
+ The DS RR links the authentication chain across zone boundaries, so
+ the DS RR requires extra care in processing. The DNSKEY RR referred
+ to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 20]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ have Flags bit 7 set to value 1. If the DNSKEY flags do not indicate
+ a DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT
+ be used in the validation process.
+
+5.3 The DS RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Key Tag field MUST be represented as an unsigned decimal integer.
+
+ The Algorithm field MUST be represented either as an unsigned decimal
+ integer or as an algorithm mnemonic specified in Appendix A.1.
+
+ The Digest Type field MUST be represented as an unsigned decimal
+ integer.
+
+ The Digest MUST be represented as a sequence of case-insensitive
+ hexadecimal digits. Whitespace is allowed within the hexadecimal
+ text.
+
+5.4 DS RR Example
+
+ The following example shows a DNSKEY RR and its corresponding DS RR.
+
+ dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
+ fwJr1AYtsmx3TGkJaNXVbfi/
+ 2pHm822aJ5iI9BMzNXxeYCmZ
+ DRD99WYwYqUSdjMmmAphXdvx
+ egXd/M5+X7OrzKBaMbCVdFLU
+ Uh6DhweJBjEVv5f2wwjM9Xzc
+ nOf+EPbtG9DMBmADjFDc2w/r
+ ljwvFw==
+ ) ; key id = 60485
+
+ dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
+ 98631FAD1A292118 )
+
+
+ The first four text fields specify the name, TTL, Class, and RR type
+ (DS). Value 60485 is the key tag for the corresponding
+ "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
+ used by this "dskey.example.com." DNSKEY RR. The value 1 is the
+ algorithm used to construct the digest, and the rest of the RDATA
+ text is the digest in hexadecimal.
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 21]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+6. Canonical Form and Order of Resource Records
+
+ This section defines a canonical form for resource records, a
+ canonical ordering of DNS names, and a canonical ordering of resource
+ records within an RRset. A canonical name order is required to
+ construct the NSEC name chain. A canonical RR form and ordering
+ within an RRset are required to construct and verify RRSIG RRs.
+
+6.1 Canonical DNS Name Order
+
+ For purposes of DNS security, owner names are ordered by treating
+ individual labels as unsigned left-justified octet strings. The
+ absence of a octet sorts before a zero value octet, and upper case
+ US-ASCII letters are treated as if they were lower case US-ASCII
+ letters.
+
+ To compute the canonical ordering of a set of DNS names, start by
+ sorting the names according to their most significant (rightmost)
+ labels. For names in which the most significant label is identical,
+ continue sorting according to their next most significant label, and
+ so forth.
+
+ For example, the following names are sorted in canonical DNS name
+ order. The most significant label is "example". At this level,
+ "example" sorts first, followed by names ending in "a.example", then
+ names ending "z.example". The names within each level are sorted in
+ the same way.
+
+ example
+ a.example
+ yljkjljk.a.example
+ Z.a.example
+ zABC.a.EXAMPLE
+ z.example
+ \001.z.example
+ *.z.example
+ \200.z.example
+
+
+6.2 Canonical RR Form
+
+ For purposes of DNS security, the canonical form of an RR is the wire
+ format of the RR where:
+ 1. Every domain name in the RR is fully expanded (no DNS name
+ compression) and fully qualified;
+ 2. All uppercase US-ASCII letters in the owner name of the RR are
+ replaced by the corresponding lowercase US-ASCII letters;
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 22]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
+ HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
+ SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in
+ the DNS names contained within the RDATA are replaced by the
+ corresponding lowercase US-ASCII letters;
+ 4. If the owner name of the RR is a wildcard name, the owner name is
+ in its original unexpanded form, including the "*" label (no
+ wildcard substitution); and
+ 5. The RR's TTL is set to its original value as it appears in the
+ originating authoritative zone or the Original TTL field of the
+ covering RRSIG RR.
+
+6.3 Canonical RR Ordering Within An RRset
+
+ For purposes of DNS security, RRs with the same owner name, class,
+ and type are sorted by treating the RDATA portion of the canonical
+ form of each RR as a left-justified unsigned octet sequence where the
+ absence of an octet sorts before a zero octet.
+
+ [RFC2181] specifies that an RRset is not allowed to contain duplicate
+ records (multiple RRs with the same owner name, class, type, and
+ RDATA). Therefore, if an implementation detects duplicate RRs when
+ putting the RRset in canonical form, the implementation MUST treat
+ this as a protocol error. If the implementation chooses to handle
+ this protocol error in the spirit of the robustness principle (being
+ liberal in what it accepts), the implementation MUST remove all but
+ one of the duplicate RR(s) for purposes of calculating the canonical
+ form of the RRset.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 23]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+7. IANA Considerations
+
+ This document introduces no new IANA considerations, because all of
+ the protocol parameters used in this document have already been
+ assigned by previous specifications. However, since the evolution of
+ DNSSEC has been long and somewhat convoluted, this section attempts
+ to describe the current state of the IANA registries and other
+ protocol parameters which are (or once were) related to DNSSEC.
+
+ Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA
+ considerations.
+
+ DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
+ the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS
+ Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47,
+ and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. [RFC3755]
+ also marked type 30 (NXT) as Obsolete, and restricted use of types
+ 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction security
+ protocol described in [RFC2931] and the transaction KEY Resource
+ Record described in [RFC2930].
+
+ DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
+ for DNSSEC Resource Record Algorithm field numbers, and assigned
+ values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755]
+ altered this registry to include flags for each entry regarding
+ its use with the DNS security extensions. Each algorithm entry
+ could refer to an algorithm that can be used for zone signing,
+ transaction security (see [RFC2931]) or both. Values 6-251 are
+ available for assignment by IETF standards action. See Appendix A
+ for a full listing of the DNS Security Algorithm Numbers entries
+ at the time of writing and their status of use in DNSSEC.
+
+ [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and
+ assigned value 0 to reserved and value 1 to SHA-1.
+
+ KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
+ Protocol Values, but [RFC3445] re-assigned all values other than 3
+ to reserved and closed this IANA registry. The registry remains
+ closed, and all KEY and DNSKEY records are required to have
+ Protocol Octet value of 3.
+
+ Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
+ registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
+ this registry only contains an assignment for bit 7 (the ZONE bit)
+ and a reservation for bit 15 for the Secure Entry Point flag (SEP
+ bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by
+ IETF Standards Action.
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 24]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+8. Security Considerations
+
+ This document describes the format of four DNS resource records used
+ by the DNS security extensions, and presents an algorithm for
+ calculating a key tag for a public key. Other than the items
+ described below, the resource records themselves introduce no
+ security considerations. Please see [I-D.ietf-dnsext-dnssec-intro]
+ and [I-D.ietf-dnsext-dnssec-protocol] for additional security
+ considerations related to the use of these records.
+
+ The DS record points to a DNSKEY RR using a cryptographic digest, the
+ key algorithm type and a key tag. The DS record is intended to
+ identify an existing DNSKEY RR, but it is theoretically possible for
+ an attacker to generate a DNSKEY that matches all the DS fields. The
+ probability of constructing such a matching DNSKEY depends on the
+ type of digest algorithm in use. The only currently defined digest
+ algorithm is SHA-1, and the working group believes that constructing
+ a public key which would match the algorithm, key tag, and SHA-1
+ digest given in a DS record would be a sufficiently difficult problem
+ that such an attack is not a serious threat at this time.
+
+ The key tag is used to help select DNSKEY resource records
+ efficiently, but it does not uniquely identify a single DNSKEY
+ resource record. It is possible for two distinct DNSKEY RRs to have
+ the same owner name, the same algorithm type, and the same key tag.
+ An implementation which uses only the key tag to select a DNSKEY RR
+ might select the wrong public key in some circumstances.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 25]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+9. Acknowledgments
+
+ This document was created from the input and ideas of the members of
+ the DNS Extensions Working Group and working group mailing list. The
+ editors would like to express their thanks for the comments and
+ suggestions received during the revision of these security extension
+ specifications. While explicitly listing everyone who has
+ contributed during the decade during which DNSSEC has been under
+ development would be an impossible task,
+ [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
+ participants who were kind enough to comment on these documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 26]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+10. References
+
+10.1 Normative References
+
+ [I-D.ietf-dnsext-dnssec-intro]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "DNS Security Introduction and Requirements",
+ draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
+ 2004.
+
+ [I-D.ietf-dnsext-dnssec-protocol]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
+ progress), May 2004.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
+ Mail Extensions) Part One: Mechanisms for Specifying and
+ Describing the Format of Internet Message Bodies", RFC
+ 1521, September 1993.
+
+ [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+ August 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+ Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+ April 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, March 1998.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 27]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+ Name System (DNS)", RFC 3110, May 2001.
+
+ [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
+ Resource Record (RR)", RFC 3445, December 2002.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+ [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
+ (RR)", RFC 3658, December 2003.
+
+ [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
+ Signer", RFC 3755, April 2004.
+
+ [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
+ Entry Point Flag", RFC 3757, April 2004.
+
+10.2 Informative References
+
+ [I-D.ietf-dnsext-nsec-rdata]
+ Schlyter, J., "KEY RR Secure Entry Point Flag",
+ draft-ietf-dnsext-nsec-rdata-05 (work in progress), March
+ 2004.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+ RR)", RFC 2930, September 2000.
+
+
+Authors' Addresses
+
+ Roy Arends
+ Telematica Instituut
+ Drienerlolaan 5
+ 7522 NB Enschede
+ NL
+
+ EMail: roy.arends@telin.nl
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 28]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ Rob Austein
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ EMail: sra@isc.org
+
+
+ Matt Larson
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ EMail: mlarson@verisign.com
+
+
+ Dan Massey
+ USC Information Sciences Institute
+ 3811 N. Fairfax Drive
+ Arlington, VA 22203
+ USA
+
+ EMail: masseyd@isi.edu
+
+
+ Scott Rose
+ National Institute for Standards and Technology
+ 100 Bureau Drive
+ Gaithersburg, MD 20899-8920
+ USA
+
+ EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 29]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+Appendix A. DNSSEC Algorithm and Digest Types
+
+ The DNS security extensions are designed to be independent of the
+ underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS
+ resource records all use a DNSSEC Algorithm Number to identify the
+ cryptographic algorithm in use by the resource record. The DS
+ resource record also specifies a Digest Algorithm Number to identify
+ the digest algorithm used to construct the DS record. The currently
+ defined Algorithm and Digest Types are listed below. Additional
+ Algorithm or Digest Types could be added as advances in cryptography
+ warrant.
+
+ A DNSSEC aware resolver or name server MUST implement all MANDATORY
+ algorithms.
+
+A.1 DNSSEC Algorithm Types
+
+ The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify
+ the security algorithm being used. These values are stored in the
+ "Algorithm number" field in the resource record RDATA.
+
+ Some algorithms are usable only for zone signing (DNSSEC), some only
+ for transaction security mechanisms (SIG(0) and TSIG), and some for
+ both. Those usable for zone signing may appear in DNSKEY, RRSIG, and
+ DS RRs. Those usable for transaction security would be present in
+ SIG(0) and KEY RRs as described in [RFC2931]
+
+ Zone
+ Value Algorithm [Mnemonic] Signing References Status
+ ----- -------------------- --------- ---------- ---------
+ 0 reserved
+ 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED
+ 2 Diffie-Hellman [DH] n RFC 2539 -
+ 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL
+ 4 Elliptic Curve [ECC] TBA -
+ 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY
+ 252 Indirect [INDIRECT] n -
+ 253 Private [PRIVATEDNS] y see below OPTIONAL
+ 254 Private [PRIVATEOID] y see below OPTIONAL
+ 255 reserved
+
+ 6 - 251 Available for assignment by IETF Standards Action.
+
+A.1.1 Private Algorithm Types
+
+ Algorithm number 253 is reserved for private use and will never be
+ assigned to a specific algorithm. The public key area in the DNSKEY
+ RR and the signature area in the RRSIG RR begin with a wire encoded
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 30]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ domain name, which MUST NOT be compressed. The domain name indicates
+ the private algorithm to use and the remainder of the public key area
+ is determined by that algorithm. Entities should only use domain
+ names they control to designate their private algorithms.
+
+ Algorithm number 254 is reserved for private use and will never be
+ assigned to a specific algorithm. The public key area in the DNSKEY
+ RR and the signature area in the RRSIG RR begin with an unsigned
+ length byte followed by a BER encoded Object Identifier (ISO OID) of
+ that length. The OID indicates the private algorithm in use and the
+ remainder of the area is whatever is required by that algorithm.
+ Entities should only use OIDs they control to designate their private
+ algorithms.
+
+A.2 DNSSEC Digest Types
+
+ A "Digest Type" field in the DS resource record types identifies the
+ cryptographic digest algorithm used by the resource record. The
+ following table lists the currently defined digest algorithm types.
+
+ VALUE Algorithm STATUS
+ 0 Reserved -
+ 1 SHA-1 MANDATORY
+ 2-255 Unassigned -
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 31]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+Appendix B. Key Tag Calculation
+
+ The Key Tag field in the RRSIG and DS resource record types provides
+ a mechanism for selecting a public key efficiently. In most cases, a
+ combination of owner name, algorithm, and key tag can efficiently
+ identify a DNSKEY record. Both the RRSIG and DS resource records
+ have corresponding DNSKEY records. The Key Tag field in the RRSIG
+ and DS records can be used to help select the corresponding DNSKEY RR
+ efficiently when more than one candidate DNSKEY RR is available.
+
+ However, it is essential to note that the key tag is not a unique
+ identifier. It is theoretically possible for two distinct DNSKEY RRs
+ to have the same owner name, the same algorithm, and the same key
+ tag. The key tag is used to limit the possible candidate keys, but it
+ does not uniquely identify a DNSKEY record. Implementations MUST NOT
+ assume that the key tag uniquely identifies a DNSKEY RR.
+
+ The key tag is the same for all DNSKEY algorithm types except
+ algorithm 1 (please see Appendix B.1 for the definition of the key
+ tag for algorithm 1). The key tag algorithm is the sum of the wire
+ format of the DNSKEY RDATA broken into 2 octet groups. First the
+ RDATA (in wire format) is treated as a series of 2 octet groups,
+ these groups are then added together ignoring any carry bits.
+
+ A reference implementation of the key tag algorithm is as an ANSI C
+ function is given below with the RDATA portion of the DNSKEY RR is
+ used as input. It is not necessary to use the following reference
+ code verbatim, but the numerical value of the Key Tag MUST be
+ identical to what the reference implementation would generate for the
+ same input.
+
+ Please note that the algorithm for calculating the Key Tag is almost
+ but not completely identical to the familiar ones complement checksum
+ used in many other Internet protocols. Key Tags MUST be calculated
+ using the algorithm described here rather than the ones complement
+ checksum.
+
+ The following ANSI C reference implementation calculates the value of
+ a Key Tag. This reference implementation applies to all algorithm
+ types except algorithm 1 (see Appendix B.1). The input is the wire
+ format of the RDATA portion of the DNSKEY RR. The code is written
+ for clarity, not efficiency.
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 32]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ /*
+ * Assumes that int is at least 16 bits.
+ * First octet of the key tag is the most significant 8 bits of the
+ * return value;
+ * Second octet of the key tag is the least significant 8 bits of the
+ * return value.
+ */
+
+ unsigned int
+ keytag (
+ unsigned char key[], /* the RDATA part of the DNSKEY RR */
+ unsigned int keysize /* the RDLENGTH */
+ )
+ {
+ unsigned long ac; /* assumed to be 32 bits or larger */
+ int i; /* loop index */
+
+ for ( ac = 0, i = 0; i < keysize; ++i )
+ ac += (i & 1) ? key[i] : key[i] << 8;
+ ac += (ac >> 16) & 0xFFFF;
+ return ac & 0xFFFF;
+ }
+
+
+B.1 Key Tag for Algorithm 1 (RSA/MD5)
+
+ The key tag for algorithm 1 (RSA/MD5) is defined differently than the
+ key tag for all other algorithms, for historical reasons. For a
+ DNSKEY RR with algorithm 1, the key tag is defined to be the most
+ significant 16 bits of the least significant 24 bits in the public
+ key modulus (in other words, the 4th to last and 3rd to last octets
+ of the public key modulus).
+
+ Please note that Algorithm 1 is NOT RECOMMENDED.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 33]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 34]
+
+Internet-Draft DNSSEC Resource Records May 2004
+
+
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires November 15, 2004 [Page 35]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-mdns-29.txt b/doc/draft/draft-ietf-dnsext-mdns-30.txt index 1a51b690..15375739 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-29.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-30.txt @@ -1,1555 +1,1868 @@ - - -DNSEXT Working Group Levon Esibov -INTERNET-DRAFT Bernard Aboba -Category: Standards Track Dave Thaler -<draft-ietf-dnsext-mdns-29.txt> Microsoft -20 January 2004 - - - Linklocal Multicast Name Resolution (LLMNR) - -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. - -Copyright Notice - -Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - -Today, with the rise of home networking, there are an increasing number -of ad-hoc networks operating without a Domain Name System (DNS) server. -In order to allow name resolution in such environments, Link-Local -Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all -current and future DNS formats, types and classes, while operating on a -separate port from DNS, and with a distinct resolver cache. - -The goal of LLMNR is to enable name resolution in scenarios in which -conventional DNS name resolution is not possible. Since LLMNR only -operates on the local link, it cannot be considered a substitute for -DNS. - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 1] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -Table of Contents - -1. Introduction .......................................... 3 - 1.1 Requirements .................................... 3 - 1.2 Terminology ..................................... 4 -2. Name resolution using LLMNR ........................... 4 - 2.1 LLMNR packet format ............................. 5 - 2.2 Sender behavior ................................. 8 - 2.3 Responder behavior .............................. 8 - 2.4 Unicast queries ................................. 10 - 2.5 Off-link detection .............................. 11 - 2.6 Responder responsibilities ...................... 12 - 2.7 Retransmission and jitter ....................... 13 - 2.8 DNS TTL ......................................... 14 - 2.9 Use of the authority and additional sections .... 14 -3. Usage model ........................................... 14 - 3.1 LLMNR configuration ............................. 15 -4. Conflict resolution ................................... 16 - 4.1 Considerations for multiple interfaces .......... 18 - 4.2 API issues ...................................... 19 -5. Security considerations ............................... 20 - 5.1 Scope restriction ............................... 20 - 5.2 Usage restriction ............................... 21 - 5.3 Cache and port separation ....................... 22 - 5.4 Authentication .................................. 22 -6. IANA considerations ................................... 22 -7. References ............................................ 22 - 7.1 Normative References ............................ 22 - 7.2 Informative References .......................... 23 -Acknowledgments .............................................. 24 -Authors' Addresses ........................................... 25 -Intellectual Property Statement .............................. 25 -Full Copyright Statement ..................................... 26 - - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 2] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -1. Introduction - -This document discusses Link Local Multicast Name Resolution (LLMNR), -which utilizes the DNS packet format and supports all current and future -DNS formats, types and classes. LLMNR operates on a separate port from -the Domain Name System (DNS), with a distinct resolver cache. - -The goal of LLMNR is to enable name resolution in scenarios in which -conventional DNS name resolution is not possible. These include -scenarios in which hosts are not configured with the address of a DNS -server, where configured DNS servers do not reply to a query, or where -they respond with errors, as described in Section 2. Since LLMNR only -operates on the local link, it cannot be considered a substitute for -DNS. - -Link-scope multicast addresses are used to prevent propagation of LLMNR -traffic across routers, potentially flooding the network. LLMNR queries -can also be sent to a unicast address, as described in Section 2.4. - -Propagation of LLMNR packets on the local link is considered sufficient -to enable name resolution in small networks. The assumption is that if -a network has a gateway, then the network is able to provide DNS server -configuration. Configuration issues are discussed in Section 3.1. - -In the future, it may be desirable to consider use of multicast name -resolution with multicast scopes beyond the link-scope. This could -occur if LLMNR deployment is successful, the need for multicast name -resolution beyond the link-scope, or multicast routing becomes -ubiquitous. For example, expanded support for multicast name resolution -might be required for mobile ad-hoc networking scenarios, or where no -DNS server is available that is authoritative for the names of local -hosts, and can support dynamic DNS, such as in wireless hotspots. - -Once we have experience in LLMNR deployment in terms of administrative -issues, usability and impact on the network, it will be possible to -reevaluate which multicast scopes are appropriate for use with multicast -name resolution. - -Service discovery in general, as well as discovery of DNS servers using -LLMNR in particular, is outside of the scope of this document, as is -name resolution over non-multicast capable media. - -1.1. Requirements - -In this document, several words are used to signify the requirements of -the specification. These words are often capitalized. The key words -"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD -NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be - - - -Esibov, Aboba & Thaler Standards Track [Page 3] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -interpreted as described in [RFC2119]. - -1.2. Terminology - -This document assumes familiarity with DNS terminology defined in -[RFC1035]. Other terminology used in this document includes: - -Positively Resolved - Responses with RCODE set to zero are referred to in this document - as "positively resolved". - -Routable Address - An address other than a Link-Local address. This includes globally - routable addresses, as well as private addresses. - -Reachable - An address is considered reachable over a link if either an ARP or - neighbor discovery cache entry exists for the address on the link. - -Responder - A host that listens to LLMNR queries, and responds to those for - which it is authoritative. - -Sender - A host that sends an LLMNR query. - -2. Name resolution using LLMNR - -LLMNR is a peer-to-peer name resolution protocol that is not intended as -a replacement for DNS. LLMNR queries are sent to and received on port -TBD. IPv4 administratively scoped multicast usage is specified in -"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope -multicast address a given responder listens to, and to which a sender -sends queries, is TBD. The IPv6 link-scope multicast address a given -responder listens to, and to which a sender sends all queries, is TBD. - -Typically a host is configured as both an LLMNR sender and a responder. -A host MAY be configured as a sender, but not a responder. However, a -host configured as a responder MUST act as a sender to verify the -uniqueness of names as described in Section 4. This document does not -specify how names are chosen or configured. This may occur via any -mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. - -LLMNR usage MAY be configured manually or automatically on a per -interface basis. By default, LLMNR responders SHOULD be enabled on all -interfaces, at all times. Enabling LLMNR for use in situations where a -DNS server has been configured will result in a change in default -behavior without a simultaneous update to configuration information. - - - -Esibov, Aboba & Thaler Standards Track [Page 4] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -Where this is considered undesirable, LLMNR SHOULD NOT be enabled by -default, so that hosts will neither listen on the link-scope multicast -address, nor will they send queries to that address. - -An LLMNR sender may send a request for any name. However, by default, -LLMNR requests SHOULD be sent only when one of the following conditions -are met: - -[1] No manual or automatic DNS configuration has been performed. If an - interface has been configured with DNS server address(es), then - LLMNR SHOULD NOT be used as the primary name resolution mechanism - on that interface, although it MAY be used as a name resolution - mechanism of last resort. - -[2] DNS servers do not respond. - -[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name - Error) or RCODE=0, and an empty answer section. - -A typical sequence of events for LLMNR usage is as follows: - -[a] DNS servers are not configured or do not respond to a DNS query, or - respond with RCODE=3, or RCODE=0 and an empty answer section. - -[b] An LLMNR sender sends an LLMNR query to the link-scope multicast - address(es) defined in Section 2, unless a unicast query is - indicated. A sender SHOULD send LLMNR queries for PTR RRs via - unicast, as specified in Section 2.4. - -[c] A responder responds to this query only if it is authoritative for - the domain name in the query. A responder responds to a multicast - query by sending a unicast UDP response to the sender. Unicast - queries are responded to as indicated in Section 2.4. - -[d] Upon reception of the response, the sender processes it. - -Further details of sender and responder behavior are provided in the -sections that follow. - -2.1. LLMNR packet format - -LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for -both queries and responses. LLMNR implementations SHOULD send UDP -queries and responses only as large as are known to be permissible -without causing fragmentation. When in doubt a maximum packet size of -512 octets SHOULD be used. LLMNR implementations MUST accept UDP -queries and responses as large as permitted by the link MTU. - - - - -Esibov, Aboba & Thaler Standards Track [Page 5] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -2.1.1. LLMNR header format - -LLMNR queries and responses utilize the DNS header format defined in -[RFC1035] with exceptions noted below: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| ID | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -|QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| QDCOUNT | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| ANCOUNT | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| NSCOUNT | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ -| ARCOUNT | -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -ID A 16 bit identifier assigned by the program that generates any kind - of query. This identifier is copied from the query to the response - and can be used by the sender to match responses to outstanding - queries. The ID field in a query SHOULD be set to a pseudo-random - value. - -QR A one bit field that specifies whether this message is an LLMNR - query (0), or an LLMNR response (1). - -OPCODE - A four bit field that specifies the kind of query in this message. - This value is set by the originator of a query and copied into the - response. This specification defines the behavior of standard - queries and responses (opcode value of zero). Future - specifications may define the use of other opcodes with LLMNR. - LLMNR senders and responders MUST support standard queries (opcode - value of zero). LLMNR queries with unsupported OPCODE values MUST - be silently discarded by responders. - -TC TrunCation - specifies that this message was truncated due to - length greater than that permitted on the transmission channel. - The TC bit MUST NOT be set in an LLMNR query and if set is ignored - by an LLMNR responder. If the TC bit is set an LLMNR response, - then the sender MAY use the response if it contains all necessary - information, or the sender MAY discard the response and resend the - - - -Esibov, Aboba & Thaler Standards Track [Page 6] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - - LLMNR query over TCP using the unicast address of the responder as - the destination address. See [RFC2181] and Section 2.4 of this - specification for further discussion of the TC bit. - -Z Reserved for future use. Implementations of this specification - MUST set these bits to zero in both queries and responses. If - these bits are set in a LLMNR query or response, implementations of - this specification MUST ignore them. Since reserved bits could - conceivably be used for different purposes than in DNS, - implementors are advised not to enable processing of these bits in - an LLMNR implementation starting from a DNS code base. - -RCODE - Response code -- this 4 bit field is set as part of LLMNR - responses. In an LLMNR query, the RCODE MUST be zero, and is - ignored by the responder. The response to a multicast LLMNR query - MUST have RCODE set to zero. A sender MUST silently discard an - LLMNR response with a non-zero RCODE sent in response to a - multicast query. - - If an LLMNR responder is authoritative for the name in a multicast - query, but an error is encountered, the responder SHOULD send an - LLMNR response with an RCODE of zero, no RRs in the answer section, - and the TC bit set. This will cause the query to be resent using - TCP, and allow the inclusion of a non-zero RCODE in the response to - the TCP query. Responding with the TC bit set is preferrable to - not sending a response, since it enables errors to be diagnosed. - - Since LLMNR responders only respond to LLMNR queries for names for - which they are authoritative, LLMNR responders MUST NOT respond - with an RCODE of 3; instead, they should not respond at all. - - LLMNR implementations MUST support EDNS0 [RFC2671] and extended - RCODE values. - -QDCOUNT - An unsigned 16 bit integer specifying the number of entries in the - question section. A sender MUST place only one question into the - question section of an LLMNR query. LLMNR responders MUST silently - discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders - MUST silently discard LLMNR responses with QDCOUNT not equal to - one. - -ANCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the answer section. LLMNR responders MUST silently - discard LLMNR queries with ANCOUNT not equal to zero. - - - - -Esibov, Aboba & Thaler Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -NSCOUNT - An unsigned 16 bit integer specifying the number of name server - resource records in the authority records section. Authority - record section processing is described in Section 2.9. - -ARCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the additional records section. Additional record - section processing is described in Section 2.9. - -2.2. Sender behavior - -A sender may send an LLMNR query for any legal resource record type -(e.g. A, AAAA, SRV, etc.) to the link-scope multicast address. - -As described in Section 2.4, a sender may also send a unicast query. -Sections 2 and 3 describe the circumstances in which LLMNR queries may -be sent. - -The sender MUST anticipate receiving no replies to some LLMNR queries, -in the event that no responders are available within the link-scope or -in the event no positive non-null responses exist for the transmitted -query. If no positive response is received, a resolver treats it as a -response that no records of the specified type and class exist for the -specified name (it is treated the same as a response with RCODE=0 and an -empty answer section). - -Since the responder may order the RRs in the response so as to indicate -preference, the sender SHOULD preserve ordering in the response to the -querying application. - -2.3. Responder behavior - -An LLMNR response MUST be sent to the sender via unicast. - -Upon configuring an IP address responders typically will synthesize -corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR -queries for these RRs. An SOA RR is synthesized only when a responder -has another RR as well; the SOA RR MUST NOT be the only RR that a -responder has. However, in general whether RRs are manually or -automatically created is an implementation decision. - -For example, a host configured to have computer name "host1" and to be a -member of the "example.com" domain, and with IPv4 address 10.1.1.1 and -IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the -following records: - -host1. IN A 10.1.1.1 - - - -Esibov, Aboba & Thaler Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - -host1.example.com. IN A 10.1.1.1 -IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - -1.1.1.10.in-addr.arpa. IN PTR host1. -IN PTR host1.example.com. - -6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa -IN PTR host1. -IN PTR host1.example.com - -An LLMNR responder might be further manually configured with the name of -a local mail server with an MX RR included in the "host1." and -"host1.example.com." records. - -In responding to queries: - -[a] Responders MUST listen on UDP port TBD on the link-scope multicast - address(es) defined in Section 2, and on UDP and TCP port TBD on - the unicast address(es) that could be set as the source address(es) - when the responder responds to the LLMNR query. - -[b] Responders MUST direct responses to the port from which the query - was sent. When queries are received via TCP this is an inherent - part of the transport protocol. For queries received by UDP the - responder MUST take note of the source port and use that as the - destination port in the response. Responses SHOULD always be sent - from the port to which they were directed. - -[c] Responders MUST respond to LLMNR queries for names and addresses - they are authoritative for. This applies to both forward and - reverse lookups. - -[d] Responders MUST NOT respond to LLMNR queries for names they are not - authoritative for. - -[e] Responders MUST NOT respond using cached data. - -[f] If a DNS server is running on a host that supports LLMNR, the DNS - server MUST respond to LLMNR queries only for the RRSets relating - to the host on which the server is running, but MUST NOT respond - for other records for which the server is authoritative. DNS - servers also MUST NOT send LLMNR queries in order to resolve DNS - queries. - -[g] If a responder is authoritative for a name, it MAY respond with - RCODE=0 and an empty answer section, if the type of query does not - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - - match a RR that the responder has. - -As an example, a host configured to respond to LLMNR queries for the -name "foo.example.com." is authoritative for the name -"foo.example.com.". On receiving an LLMNR query for an A RR with the -name "foo.example.com." the host authoritatively responds with A RR(s) -that contain IP address(es) in the RDATA of the resource record. If the -responder has a AAAA RR, but no A RR, and an A RR query is received, the -responder would respond with RCODE=0 and an empty answer section. - -In conventional DNS terminology a DNS server authoritative for a zone is -authoritative for all the domain names under the zone apex except for -the branches delegated into separate zones. Contrary to conventional -DNS terminology, an LLMNR responder is authoritative only for the zone -apex. - -For example the host "foo.example.com." is not authoritative for the -name "child.foo.example.com." unless the host is configured with -multiple names, including "foo.example.com." and -"child.foo.example.com.". As a result, "foo.example.com." cannot reply -to an LLMNR query for "child.foo.example.com." with RCODE=3 -(authoritative name error). The purpose of limiting the name authority -scope of a responder is to prevent complications that could be caused by -coexistence of two or more hosts with the names representing child and -parent (or grandparent) nodes in the DNS tree, for example, -"foo.example.com." and "child.foo.example.com.". - -In this example (unless this limitation is introduced) an LLMNR query -for an A resource record for the name "child.foo.example.com." would -result in two authoritative responses: RCODE=3 (authoritative name -error) received from "foo.example.com.", and a requested A record - from -"child.foo.example.com.". To prevent this ambiguity, LLMNR enabled -hosts could perform a dynamic update of the parent (or grandparent) zone -with a delegation to a child zone. In this example a host -"child.foo.example.com." would send a dynamic update for the NS and glue -A record to "foo.example.com.", but this approach significantly -complicates implementation of LLMNR and would not be acceptable for -lightweight hosts. - -2.4. Unicast queries and responses - -Unicast queries SHOULD be sent when: - -[a] A sender repeats a query after it received a response with the TC - bit set to the previous LLMNR multicast query, or - -[b] The sender queries for a PTR RR of a fully formed IP address within - the "in-addr.arpa" or "ip6.arpa" zones. - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -A responder receiving a unicast query MUST send the response with a -source address set to the destination address field of the IP header of -the query causing the response. - -Unicast LLMNR queries SHOULD be sent using TCP. Senders MUST support -sending TCP queries, and responders MUST support listening for TCP -queries. - -Responses to TCP unicast LLMNR queries MUST be sent using TCP, using -the same connection as the query. If the sender of a TCP query receives -a response to that query not using TCP, the response MUST be silently -discarded. - -Unicast UDP queries MAY be responded to with a UDP response containing -an empty answer section and the TC bit set, so as to require the sender -to resend the query using TCP. - -If an ICMP "Time Exceeded" message is received in response to a unicast -UDP query, or if TCP connection setup cannot be completed in order to -send a unicast TCP query, this is treated as a response that no records -of the specified type and class exist for the specified name (it is -treated the same as a response with RCODE=0 and an empty answer -section). The UDP sender receiving an ICMP "Time Exceeded" message -SHOULD verify that the ICMP error payload contains a valid LLMNR query -packet, which matches a query that is currently in progress, so as to -guard against a potential Denial of Service (DoS) attack. If a match -cannot be made, then the sender relies on the retransmission and timeout -behavior described in Section 2.7. - -2.5. "Off link" detection - -For IPv4, an "on link" address is defined as a link-local address -[IPv4Link] or an address whose prefix belongs to a subnet on the local -link. For IPv6 [RFC2460] an "on link" address is either a link-local -address, defined in [RFC2373], or an address whose prefix belongs to a -subnet on the local link. - -A sender MUST select a source address for LLMNR queries that is "on -link". The destination address of an LLMNR query MUST be a link-scope -multicast address or an "on link" unicast address. - -A responder MUST select a source address for responses that is "on -link". The destination address of an LLMNR response MUST be an "on link" -unicast address. - -On receiving an LLMNR query, the responder MUST check whether it was -sent to a LLMNR multicast addresses defined in Section 2. If it was -sent to another multicast address, then the query MUST be silently - - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -discarded. - -In composing LLMNR queries, the sender MUST set the Hop Limit field in -the IPv6 header and the TTL field in IPv4 header of the response to one -(1). Even when LLMNR queries are sent to a link-scope multicast -address, it is possible that some routers may not properly implement -link-scope multicast, or that link-scope multicast addresses may leak -into the multicast routing system. Therefore setting the IPv6 Hop Limit -or IPv4 TTL field to one provides an additional precaution against -leakage of LLMNR queries. - -In composing a response to an LLMNR query, the responder MUST set the -Hop Limit field in the IPv6 header and the TTL field in IPv4 header of -the response to one (1). This is done so as to prevent the use of LLMNR -for denial of service attacks across the Internet. - -Section 2.4 discusses use of TCP for LLMNR queries and responses. The -responder SHOULD set the TTL or Hop Limit settings on the TCP listen -socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop -Limit (IPv6) set to one (1). This prevents an incoming connection from -off-link since the sender will not receive a SYN-ACK from the responder. - -Implementation note: - - In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL - socket options are used to set the TTL of outgoing unicast and - multicast packets. The IP_RECVTTL socket option is available on some - platforms to retrieve the IPv4 TTL of received packets with - recvmsg(). [RFC2292] specifies similar options for setting and - retrieving the IPv6 Hop Limit. - -2.6. Responder responsibilities - -It is the responsibility of the responder to ensure that RRs returned in -LLMNR responses MUST only include values that are valid on the local -interface, such as IPv4 or IPv6 addresses valid on the local link or -names defended using the mechanism described in Section 4. In -particular: - -[a] If a link-scope IPv6 address is returned in a AAAA RR, that address - MUST be valid on the local link over which LLMNR is used. - -[b] If an IPv4 address is returned, it MUST be reachable through the - link over which LLMNR is used. - -[c] If a name is returned (for example in a CNAME, MX or SRV RR), the - name MUST be resolvable on the local link over which LLMNR is used. - - - - -Esibov, Aboba & Thaler Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -Routable addresses MUST be included first in the response, if available. -This encourages use of routable address(es) for establishment of new -connections. - -2.7. Retransmission and jitter - -An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine -when to retransmit an LLMNR query and how long to collect responses to -an LLMNR query. - -If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, -then a sender MAY repeat the transmission of the query in order to -assure that it was received by a host capable of responding to it. -Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. -Where LLMNR queries are sent using TCP, retransmission is handled by the -transport layer. - -Because an LLMNR sender cannot know in advance if a query sent using -multicast will receive no response, one response, or more than one -response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect -all possible responses, rather than considering the multicast query -answered after the first response is received. A unicast query sender -considers the query answered after the first response is received, so -that it only waits for LLMNR_TIMEOUT if no response has been received. - -An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT -for each transmission. It is suggested that the computation of -LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries -sent on the same interface. - -For example, the algorithms described in RFC 2988 [RFC2988] (including -exponential backoff) to compute an RTO, which is used as the value of -LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed -in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in -Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed -in Section 2 of [RFC2988], paragraph 2.5). - -Recommended values are an initial RTO of 1 second, a minimum RTO of -200ms, and a maximum RTO of 5 seconds. In order to avoid -synchronization, the transmission of each LLMNR query and response -SHOULD delayed by a time randomly selected from the interval 0 to 100 -ms. This delay MAY be avoided by responders responding with RRs which -they have previously determined to be UNIQUE (see Section 4 for -details). - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -2.8. DNS TTL - -The responder should use a pre-configured TTL value in the records -returned an LLMNR response. A default value of 30 seconds is -RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc -networks), the TTL value may need to be reduced. - -Due to the TTL minimalization necessary when caching an RRset, all TTLs -in an RRset MUST be set to the same value. - -2.9. Use of the authority and additional sections - -Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a -concept of delegation. In LLMNR, the NS resource record type may be -stored and queried for like any other type, but it has no special -delegation semantics as it does in the DNS. Responders MAY have NS -records associated with the names for which they are authoritative, but -they SHOULD NOT include these NS records in the authority sections of -responses. - -Responders SHOULD insert an SOA record into the authority section of a -negative response, to facilitate negative caching as specified in -[RFC2308]. The owner name of this SOA record MUST be equal to the query -name. - -Responders SHOULD NOT perform DNS additional section processing, except -as required for EDNS0 and DNSSEC. - -Senders MUST NOT cache RRs from the authority or additional section of a -response as answers, though they may be used for other purposes such as -negative caching. - -3. Usage model - -Since LLMNR is a secondary name resolution mechanism, its usage is in -part determined by the behavior of DNS implementations. This document -does not specify any changes to DNS resolver behavior, such as -searchlist processing or retransmission/failover policy. However, -robust DNS resolver implementations are more likely to avoid unnecessary -LLMNR queries. - -As noted in [DNSPerf], even when DNS servers are configured, a -significant fraction of DNS queries do not receive a response, or result -in negative responses due to missing inverse mappings or NS records that -point to nonexistent or inappropriate hosts. This has the potential to -result in a large number of unnecessary LLMNR queries. - -[RFC1536] describes common DNS implementation errors and fixes. If the - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -proposed fixes are implemented, unnecessary LLMNR queries will be -reduced substantially, and so implementation of [RFC1536] is -recommended. - -For example, [RFC1536] Section 1 describes issues with retransmission -and recommends implementation of a retransmission policy based on round -trip estimates, with exponential backoff. [RFC1536] Section 4 describes -issues with failover, and recommends that resolvers try another server -when they don't receive a response to a query. These policies are -likely to avoid unnecessary LLMNR queries. - -[RFC1536] Section 3 describes zero answer bugs, which if addressed will -also reduce unnecessary LLMNR queries. - -[RFC1536] Section 6 describes name error bugs and recommended searchlist -processing that will reduce unnecessary RCODE=3 (authoritative name) -errors, thereby also reducing unnecessary LLMNR queries. - -3.1. LLMNR configuration - -Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is -possible for a dual stack host to be configured with the address of a -DNS server over IPv4, while remaining unconfigured with a DNS server -suitable for use over IPv6. - -In these situations, a dual stack host will send AAAA queries to the -configured DNS server over IPv4. However, an IPv6-only host -unconfigured with a DNS server suitable for use over IPv6 will be unable -to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms -(such as [RFC3315] and [DNSDisc]) are not yet widely deployed, and not -all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration -may be a common problem in the short term, and LLMNR may prove useful in -enabling linklocal name resolution over IPv6. - -Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], -IPv6-only hosts may not be configured with a DNS server. Where there is -no DNS server authoritative for the name of a host or the authoritative -DNS server does not support dynamic client update over IPv6 or -DHCPv6-based dynamic update, then an IPv6-only host will not be able to -do DNS dynamic update, and other hosts will not be able to resolve its -name. - -For example, if the configured DNS server responds to AAAA RR queries -sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then -it will not be possible to resolve the names of IPv6-only hosts. In -this situation, LLMNR over IPv6 can be used for local name resolution. - -Similarly, if a DHCPv4 server is available providing DNS server - - - -Esibov, Aboba & Thaler Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -configuration, and DNS server(s) exist which are authoritative for the A -RRs of local hosts and support either dynamic client update over IPv4 or -DHCPv4-based dynamic update, then the names of local IPv4 hosts can be -resolved over IPv4 without LLMNR. However, if no DNS server is -authoritative for the names of local hosts, or the authoritative DNS -server(s) do not support dynamic update, then LLMNR enables linklocal -name resolution over IPv4. - -Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to -configure LLMNR on an interface. The LLMNR Enable Option, described in -[LLMNREnable], can be used to explicitly enable or disable use of LLMNR -on an interface. The LLMNR Enable Option does not determine whether or -in which order DNS itself is used for name resolution. The order in -which various name resolution mechanisms should be used can be specified -using the Name Service Search Option (NSSO) for DHCP [RFC2937], using -the LLMNR Enable Option code carried in the NSSO data. - -It is possible that DNS configuration mechanisms will go in and out of -service. In these circumstances, it is possible for hosts within an -administrative domain to be inconsistent in their DNS configuration. - -For example, where DHCP is used for configuring DNS servers, one or more -DHCP servers can fail. As a result, hosts configured prior to the -outage will be configured with a DNS server, while hosts configured -after the outage will not. Alternatively, it is possible for the DNS -configuration mechanism to continue functioning while configured DNS -servers fail. - -Unless unconfigured hosts periodically retry configuration, an outage in -the DNS configuration mechanism will result in hosts continuing to use -LLMNR even once the outage is repaired. Since LLMNR only enables -linklocal name resolution, this represents an unnecessary degradation in -capabilities. As a result, it is recommended that hosts without a -configured DNS server periodically attempt to obtain DNS configuration. -For example, where DHCP is used for DNS configuration, [RFC2131] -recommends a maximum retry interval of 64 seconds. In the absence of -other guidance, a default retry interval of one (1) minute is -RECOMMENDED. - -4. Conflict resolution - -The sender MUST anticipate receiving multiple replies to the same LLMNR -query, in the event that several LLMNR enabled computers receive the -query and respond with valid answers. When this occurs, the responses -may first be concatenated, and then treated in the same manner that -multiple RRs received from the same DNS server would; the sender -perceives no inherent conflict in the receipt of multiple responses. - - - - -Esibov, Aboba & Thaler Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -There are some scenarios when multiple responders MAY respond to the -same query. There are other scenarios when only one responder MAY -respond to a query. Resource records for which the latter queries are -submitted are referred as UNIQUE throughout this document. The -uniqueness of a resource record depends on a nature of the name in the -query and type of the query. For example it is expected that: - - - multiple hosts may respond to a query for an SRV type record - - multiple hosts may respond to a query for an A or AAAA type - record for a cluster name (assigned to multiple hosts in - the cluster) - - only a single host may respond to a query for an A or AAAA - type record for a name. - -Every responder that responds to an LLMNR query AND includes a UNIQUE -record in the response: - -[1] MUST verify that there is no other host within the scope of the - LLMNR query propagation that can return a resource record for the - same name, type and class. - -[2] MUST NOT include a UNIQUE resource record in the response without - having verified its uniqueness. - -Where a host is configured to issue LLMNR queries on more than one -interface, each interface should have its own independent LLMNR cache. -For each UNIQUE resource record in a given interface's configuration, -the host MUST verify resource record uniqueness on that interface. To -accomplish this, the host MUST send an LLMNR query for each UNIQUE -resource record. - -By default, a host SHOULD be configured to behave as though all RRs are -UNIQUE. Uniqueness verification is carried out when the host: - - - starts up or is rebooted - - wakes from sleep (if the network interface was inactive during sleep) - - is configured to respond to the LLMNR queries on an interface - enabled for transmission and reception of IP traffic - - is configured to respond to the LLMNR queries using additional - UNIQUE resource records - - detects that an interface is connected and is usable - (e.g. an IEEE 802 hardware link-state change indicating - that a cable was attached or that an association has occurred - with a wireless base station and that any required authentication - has completed) - -When a host that has a UNIQUE record receives an LLMNR query for that -record, the host MUST respond. After the client receives a response, it - - - -Esibov, Aboba & Thaler Standards Track [Page 17] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -MUST check whether the response arrived on an interface different from -the one on which the query was sent. If the response arrives on a -different interface, the client can use the UNIQUE resource record in -response to LLMNR queries. If not, then it MUST NOT use the UNIQUE -resource record in response to LLMNR queries. - -The name conflict detection mechanism doesn't prevent name conflicts -when previously partitioned segments are connected by a bridge. In order -to minimize the chance of conflicts in such a situation, it is -recommended that steps be taken to ensure name uniqueness. For example, -the name could be chosen randomly from a large pool of potential names, -or the name could be assigned via a process designed to guarantee -uniqueness. - -When name conflicts are detected, they SHOULD be logged. To detect -duplicate use of a name, an administrator can use a name resolution -utility which employs LLMNR and lists both responses and responders. -This would allow an administrator to diagnose behavior and potentially -to intervene and reconfigure LLMNR responders who should not be -configured to respond to the same name. - -4.1. Considerations for Multiple Interfaces - -A multi-homed host may elect to configure LLMNR on only one of its -active interfaces. In many situations this will be adequate. However, -should a host need to configure LLMNR on more than one of its active -interfaces, there are some additional precautions it MUST take. -Implementers who are not planning to support LLMNR on multiple -interfaces simultaneously may skip this section. - -A multi-homed host checks the uniqueness of UNIQUE records as described -in Section 4. The situation is illustrated in figure 1. - - ---------- ---------- - | | | | - [A] [myhost] [myhost] - - Figure 1. Link-scope name conflict - -In this situation, the multi-homed myhost will probe for, and defend, -its host name on both interfaces. A conflict will be detected on one -interface, but not the other. The multi-homed myhost will not be able -to respond with a host RR for "myhost" on the interface on the right -(see Figure 1). The multi-homed host may, however, be configured to use -the "myhost" name on the interface on the left. - -Since names are only unique per-link, hosts on different links could be -using the same name. If an LLMNR client sends requests over multiple - - - -Esibov, Aboba & Thaler Standards Track [Page 18] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -interfaces, and receives replies from more than one, the result returned -to the client is defined by the implementation. The situation is -illustrated in figure 2. - - ---------- ---------- - | | | | - [A] [myhost] [A] - - - Figure 2. Off-segment name conflict - -If host myhost is configured to use LLMNR on both interfaces, it will -send LLMNR queries on both interfaces. When host myhost sends a query -for the host RR for name "A" it will receive a response from hosts on -both interfaces. - -Host myhost cannot distinguish between the situation shown in Figure 2, -and that shown in Figure 3 where no conflict exists. - - [A] - | | - ----- ----- - | | - [myhost] - - Figure 3. Multiple paths to same host - -This illustrates that the proposed name conflict resolution mechanism -does not support detection or resolution of conflicts between hosts on -different links. This problem can also occur with unicast DNS when a -multi-homed host is connected to two different networks with separated -name spaces. It is not the intent of this document to address the issue -of uniqueness of names within DNS. - -4.2. API issues - -[RFC2553] provides an API which can partially solve the name ambiguity -problem for applications written to use this API, since the sockaddr_in6 -structure exposes the scope within which each scoped address exists, and -this structure can be used for both IPv4 (using v4-mapped IPv6 -addresses) and IPv6 addresses. - -Following the example in Figure 2, an application on 'myhost' issues the -request getaddrinfo("A", ...) with ai_family=AF_INET6 and -ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both -interfaces and the resolver library will return a list containing -multiple addrinfo structures, each with an associated sockaddr_in6 -structure. This list will thus contain the IPv4 and IPv6 addresses of - - - -Esibov, Aboba & Thaler Standards Track [Page 19] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -both hosts responding to the name 'A'. Link-local addresses will have a -sin6_scope_id value that disambiguates which interface is used to reach -the address. Of course, to the application, Figures 2 and 3 are still -indistinguishable, but this API allows the application to communicate -successfully with any address in the list. - -5. Security Considerations - -LLMNR is by nature a peer-to-peer name resolution protocol. It is -therefore inherently more vulnerable than DNS, since existing DNS -security mechanisms are difficult to apply to LLMNR. While tools exist -to alllow an attacker to spoof a response to a DNS query, spoofing a -response to an LLMNR query is easier since the query is sent to a link- -scope multicast address, where every host on the logical link will be -made aware of it. - -In order to address the security vulnerabilities, the following -mechanisms are contemplated: - -[1] Scope restrictions. - -[2] Usage restrictions. - -[3] Cache and port separation. - -[4] Authentication. - -These techniques are described in the following sections. - -5.1. Scope restriction - -With LLMNR it is possible that hosts will allocate conflicting names for -a period of time, or that attackers will attempt to deny service to -other hosts by allocating the same name. Such attacks also allow hosts -to receive packets destined for other hosts. - -Since LLMNR is typically deployed in situations where no trust model can -be assumed, it is likely that LLMNR queries and responses will be -unauthenticated. In the absence of authentication, LLMNR reduces the -exposure to such threats by utilizing queries sent to a link-scope -multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) -fields to one (1) on both queries and responses. - -A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can -be used to launch denial of service attacks. For example, were the TTL -of an LLMNR Response to be set to a value larger than one (1), an -attacker could send a large volume of queries from a spoofed source -address, causing an off-link target to be deluged with responses. - - - -Esibov, Aboba & Thaler Standards Track [Page 20] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -Utilizing a TTL of one (1) in LLMNR responses ensures that they will not -be forwarded off-link. Using a TTL of one (1) to set up a TCP connection -in order to send a unicast LLMNR query reduces the likelihood of both -denial of service attacks and spoofed responses. Checking that an LLMNR -query is sent to a link-scope multicast address should prevent spoofing -of multicast queries by off-link attackers. - -While this limits the ability of off-link attackers to spoof LLMNR -queries and responses, it does not eliminate it. For example, it is -possible for an attacker to spoof a response to a frequent query (such -as an A or AAAA query for a popular Internet host), and by using a TTL -or Hop Limit field larger than one (1), for the forged response to reach -the LLMNR sender. - -There also are scenarios such as public "hotspots" where attackers can -be present on the same link. These threats are most serious in wireless -networks such as 802.11, since attackers on a wired network will require -physical access to the home network, while wireless attackers may reside -outside the home. Link-layer security can be of assistance against -these threats if it is available. - -5.2. Usage restriction - -As noted in Sections 2 and 3, LLMNR is intended for usage in a limited -set of scenarios. - -If an LLMNR query is sent whenever a DNS server does not respond in a -timely way, then an attacker can poison the LLMNR cache by responding to -the query with incorrect information. To some extent, these -vulnerabilities exist today, since DNS response spoofing tools are -available that can allow an attacker to respond to a query more quickly -than a distant DNS server. - -Since LLMNR queries are sent and responded to on the local-link, an -attacker will need to respond more quickly to provide its own response -prior to arrival of the response from a legitimate responder. If an -LLMNR query is sent for an off-link host, spoofing a response in a -timely way is not difficult, since a legitimate response will never be -received. - -The vulnerability is more serious if LLMNR is given higher priority than -DNS among the enabled name resolution mechanisms. In such a -configuration, a denial of service attack on the DNS server would not be -necessary in order to poison the LLMNR cache, since LLMNR queries would -be sent even when the DNS server is available. In addition, the LLMNR -cache, once poisoned, would take precedence over the DNS cache, -eliminating the benefits of cache separation. As a result, LLMNR is only -used as a name resolution mechanism of last resort. - - - -Esibov, Aboba & Thaler Standards Track [Page 21] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -5.3. Cache and port separation - -In order to prevent responses to LLMNR queries from polluting the DNS -cache, LLMNR implementations MUST use a distinct, isolated cache for -LLMNR on each interface. The use of separate caches is most effective -when LLMNR is used as a name resolution mechanism of last resort, since -this minimizes the opportunities for poisoning the LLMNR cache, and -decreases reliance on it. - -LLMNR operates on a separate port from DNS, reducing the likelihood that -a DNS server will unintentionally respond to an LLMNR query. - -5.4. Authentication - -LLMNR implementations may not support DNSSEC or TSIG, and as a result, -responses to LLMNR queries may be unauthenticated. If authentication is -desired, and a pre-arranged security configuration is possible, then -IPsec ESP with a null-transform MAY be used to authenticate LLMNR -responses. In a small network without a certificate authority, this can -be most easily accomplished through configuration of a group pre-shared -key for trusted hosts. - -6. IANA Considerations - -This specification creates one new name space: the reserved bits in the -LLMNR header. These are allocated by IETF Consensus, in accordance with -BCP 26 [RFC2434]. - -LLMNR requires allocation of a port TBD for both TCP and UDP. -Assignment of the same port for both transports is requested. - -LLMNR requires allocation of a link-scope multicast IPv4 address TBD. -LLMNR also requires allocation of a link-scope multicast IPv6 address -TBD. - -7. References - -7.1. Normative References - -[RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, November 1987. - -[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - -[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - -Esibov, Aboba & Thaler Standards Track [Page 22] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - -[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - -[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC - 2365, July 1998. - -[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - -[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October - 1998. - -[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - -[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - -[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - -[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission - Timer", RFC 2988, November 2000. - -7.2. Informative References - -[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested - Fixes", RFC 1536, October 1993. - -[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - -[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - -[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", - RFC 2292, February 1998. - -[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic - Socket Interface Extensions for IPv6", RFC 2553, March 1999. - -[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC - 2937, September 2000. - - - -Esibov, Aboba & Thaler Standards Track [Page 23] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - -[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of - Caching", IEEE/ACM Transactions on Networking, Volume 10, - Number 5, pp. 589, October 2002. - -[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local - unicast addresses to communicate with recursive DNS servers", - Internet draft (work in progress), draft-ietf-ipv6-dns- - discovery-07.txt, October 2002. - -[IPV4Link] - Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of IPv4 Link-Local Addresses", Internet draft (work in - progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October - 2003. - -[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- - Portable Operating System Interface (POSIX). Open Group - Technical Standard: Base Specifications, Issue 6, December - 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin - -[LLMNREnable] - Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work - in progress), draft-guttman-mdns-enable-02.txt, April 2002. - -[NodeInfo] - Crawford, M., "IPv6 Node Information Queries", Internet draft - (work in progress), draft-ietf-ipn-gwg-icmp-name- - lookups-09.txt, May 2002. - -Acknowledgments - -This work builds upon original work done on multicast DNS by Bill -Manning and Bill Woodcock. Bill Manning's work was funded under DARPA -grant #F30602-99-1-0523. The authors gratefully acknowledge their -contribution to the current specification. Constructive input has also -been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert -Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron -Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van- -Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku -Savela. - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 24] - - - - - -INTERNET-DRAFT LLMNR 20 January 2004 - - -Authors' Addresses - -Levon Esibov -Microsoft Corporation -One Microsoft Way -Redmond, WA 98052 - -EMail: levone@microsoft.com - -Bernard Aboba -Microsoft Corporation -One Microsoft Way -Redmond, WA 98052 - -Phone: +1 425 706 6605 -EMail: bernarda@microsoft.com - -Dave Thaler -Microsoft Corporation -One Microsoft Way -Redmond, WA 98052 - -Phone: +1 425 703 8835 -EMail: dthaler@microsoft.com - -Intellectual Property Statement - -The IETF takes no position regarding the validity or scope of any -intellectual property or other rights that might be claimed to pertain -to the implementation or use of the technology described in this -document or the extent to which any license under such rights might or -might not be available; neither does it represent that it has made any -effort to identify any such rights. Information on the IETF's -procedures with respect to rights in standards-track and standards- -related documentation can be found in BCP-11. Copies of claims of -rights made available for publication and any assurances of licenses to -be made available, or the result of an attempt made to obtain a general -license or permission for the use of such proprietary rights by -implementors or users of this specification can be obtained from the -IETF Secretariat. - -The IETF invites any interested party to bring to its attention any -copyrights, patents or patent applications, or other proprietary rights -which may cover technology that may be required to practice this -standard. Please address the information to the IETF Executive -Director. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 25] - - - - - -INTERNET-DRAFT LLMNR 20 January 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. - -Open Issues - -Open issues with this specification are tracked on the following web -site: - -http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html - -Expiration Date - -This memo is filed as <draft-ietf-dnsext-mdns-29.txt>, and expires -August 4, 2004. - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 26] - +DNSEXT Working Group Levon Esibov
+INTERNET-DRAFT Bernard Aboba
+Category: Standards Track Dave Thaler
+<draft-ietf-dnsext-mdns-30.txt> Microsoft
+17 March 2004
+
+
+
+ Linklocal Multicast Name Resolution (LLMNR)
+
+
+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.
+
+
+Copyright Notice
+
+
+Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+
+Abstract
+
+
+Today, with the rise of home networking, there are an increasing number
+of ad-hoc networks operating without a Domain Name System (DNS) server.
+In order to allow name resolution in such environments, Link-Local
+Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all
+current and future DNS formats, types and classes, while operating on a
+separate port from DNS, and with a distinct resolver cache.
+
+
+The goal of LLMNR is to enable name resolution in scenarios in which
+conventional DNS name resolution is not possible. Since LLMNR only
+operates on the local link, it cannot be considered a substitute for
+DNS.
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 1]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+Table of Contents
+
+
+1. Introduction .......................................... 3
+ 1.1 Requirements .................................... 3
+ 1.2 Terminology ..................................... 4
+2. Name resolution using LLMNR ........................... 4
+ 2.1 LLMNR packet format ............................. 5
+ 2.2 Sender behavior ................................. 8
+ 2.3 Responder behavior .............................. 8
+ 2.4 Unicast queries ................................. 10
+ 2.5 Off-link detection .............................. 11
+ 2.6 Responder responsibilities ...................... 12
+ 2.7 Retransmission and jitter ....................... 12
+ 2.8 DNS TTL ......................................... 13
+ 2.9 Use of the authority and additional sections .... 13
+3. Usage model ........................................... 14
+ 3.1 LLMNR configuration ............................. 15
+4. Conflict resolution ................................... 16
+ 4.1 Considerations for multiple interfaces .......... 18
+ 4.2 API issues ...................................... 19
+5. Security considerations ............................... 19
+ 5.1 Scope restriction ............................... 20
+ 5.2 Usage restriction ............................... 21
+ 5.3 Cache and port separation ....................... 21
+ 5.4 Authentication .................................. 22
+6. IANA considerations ................................... 22
+7. References ............................................ 22
+ 7.1 Normative References ............................ 22
+ 7.2 Informative References .......................... 23
+Acknowledgments .............................................. 24
+Authors' Addresses ........................................... 25
+Intellectual Property Statement .............................. 25
+Full Copyright Statement ..................................... 26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 2]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+1. Introduction
+
+
+This document discusses Link Local Multicast Name Resolution (LLMNR),
+which utilizes the DNS packet format and supports all current and future
+DNS formats, types and classes. LLMNR operates on a separate port from
+the Domain Name System (DNS), with a distinct resolver cache.
+
+
+The goal of LLMNR is to enable name resolution in scenarios in which
+conventional DNS name resolution is not possible. These include
+scenarios in which hosts are not configured with the address of a DNS
+server, where configured DNS servers do not reply to a query, or where
+they respond with errors, as described in Section 2. Since LLMNR only
+operates on the local link, it cannot be considered a substitute for
+DNS.
+
+
+Link-scope multicast addresses are used to prevent propagation of LLMNR
+traffic across routers, potentially flooding the network. LLMNR queries
+can also be sent to a unicast address, as described in Section 2.4.
+
+
+Propagation of LLMNR packets on the local link is considered sufficient
+to enable name resolution in small networks. The assumption is that if
+a network has a gateway, then the network is able to provide DNS server
+configuration. Configuration issues are discussed in Section 3.1.
+
+
+In the future, it may be desirable to consider use of multicast name
+resolution with multicast scopes beyond the link-scope. This could
+occur if LLMNR deployment is successful, the need for multicast name
+resolution beyond the link-scope, or multicast routing becomes
+ubiquitous. For example, expanded support for multicast name resolution
+might be required for mobile ad-hoc networking scenarios, or where no
+DNS server is available that is authoritative for the names of local
+hosts, and can support dynamic DNS, such as in wireless hotspots.
+
+
+Once we have experience in LLMNR deployment in terms of administrative
+issues, usability and impact on the network, it will be possible to
+reevaluate which multicast scopes are appropriate for use with multicast
+name resolution.
+
+
+Service discovery in general, as well as discovery of DNS servers using
+LLMNR in particular, is outside of the scope of this document, as is
+name resolution over non-multicast capable media.
+
+
+1.1. Requirements
+
+
+In this document, several words are used to signify the requirements of
+the specification. These words are often capitalized. The key words
+"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
+NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 3]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+interpreted as described in [RFC2119].
+
+
+1.2. Terminology
+
+
+This document assumes familiarity with DNS terminology defined in
+[RFC1035]. Other terminology used in this document includes:
+
+
+Positively Resolved
+ Responses with RCODE set to zero are referred to in this document
+ as "positively resolved".
+
+
+Routable Address
+ An address other than a Link-Local address. This includes globally
+ routable addresses, as well as private addresses.
+
+
+Reachable
+ An address is considered reachable over a link if either an ARP or
+ neighbor discovery cache entry exists for the address on the link.
+
+
+Responder
+ A host that listens to LLMNR queries, and responds to those for
+ which it is authoritative.
+
+
+Sender
+ A host that sends an LLMNR query.
+
+
+2. Name resolution using LLMNR
+
+
+LLMNR is a peer-to-peer name resolution protocol that is not intended as
+a replacement for DNS. LLMNR queries are sent to and received on port
+TBD. IPv4 administratively scoped multicast usage is specified in
+"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope
+multicast address a given responder listens to, and to which a sender
+sends queries, is TBD. The IPv6 link-scope multicast address a given
+responder listens to, and to which a sender sends all queries, is TBD.
+
+
+Typically a host is configured as both an LLMNR sender and a responder.
+A host MAY be configured as a sender, but not a responder. However, a
+host configured as a responder MUST act as a sender to verify the
+uniqueness of names as described in Section 4. This document does not
+specify how names are chosen or configured. This may occur via any
+mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].
+
+
+LLMNR usage MAY be configured manually or automatically on a per
+interface basis. By default, LLMNR responders SHOULD be enabled on all
+interfaces, at all times. Enabling LLMNR for use in situations where a
+DNS server has been configured will result in a change in default
+behavior without a simultaneous update to configuration information.
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 4]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+Where this is considered undesirable, LLMNR SHOULD NOT be enabled by
+default, so that hosts will neither listen on the link-scope multicast
+address, nor will they send queries to that address.
+
+
+An LLMNR sender may send a request for any name. However, by default,
+LLMNR requests SHOULD be sent only when one of the following conditions
+are met:
+
+
+[1] No manual or automatic DNS configuration has been performed. If an
+ interface has been configured with DNS server address(es), then
+ LLMNR SHOULD NOT be used as the primary name resolution mechanism
+ on that interface, although it MAY be used as a name resolution
+ mechanism of last resort.
+
+
+[2] DNS servers do not respond.
+
+
+[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name
+ Error) or RCODE=0, and an empty answer section.
+
+
+A typical sequence of events for LLMNR usage is as follows:
+
+
+[a] DNS servers are not configured or do not respond to a DNS query, or
+ respond with RCODE=3, or RCODE=0 and an empty answer section.
+
+
+[b] An LLMNR sender sends an LLMNR query to the link-scope multicast
+ address(es) defined in Section 2, unless a unicast query is
+ indicated. A sender SHOULD send LLMNR queries for PTR RRs via
+ unicast, as specified in Section 2.4.
+
+
+[c] A responder responds to this query only if it is authoritative for
+ the domain name in the query. A responder responds to a multicast
+ query by sending a unicast UDP response to the sender. Unicast
+ queries are responded to as indicated in Section 2.4.
+
+
+[d] Upon reception of the response, the sender processes it.
+
+
+Further details of sender and responder behavior are provided in the
+sections that follow.
+
+
+2.1. LLMNR packet format
+
+
+LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for
+both queries and responses. LLMNR implementations SHOULD send UDP
+queries and responses only as large as are known to be permissible
+without causing fragmentation. When in doubt a maximum packet size of
+512 octets SHOULD be used. LLMNR implementations MUST accept UDP
+queries and responses as large as permitted by the link MTU.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 5]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+2.1.1. LLMNR header format
+
+
+LLMNR queries and responses utilize the DNS header format defined in
+[RFC1035] with exceptions noted below:
+
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+| ID |
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+|QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE |
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+| QDCOUNT |
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+| ANCOUNT |
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+| NSCOUNT |
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+| ARCOUNT |
++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+where:
+
+
+ID A 16 bit identifier assigned by the program that generates any kind
+ of query. This identifier is copied from the query to the response
+ and can be used by the sender to match responses to outstanding
+ queries. The ID field in a query SHOULD be set to a pseudo-random
+ value.
+
+
+QR A one bit field that specifies whether this message is an LLMNR
+ query (0), or an LLMNR response (1).
+
+
+OPCODE
+ A four bit field that specifies the kind of query in this message.
+ This value is set by the originator of a query and copied into the
+ response. This specification defines the behavior of standard
+ queries and responses (opcode value of zero). Future
+ specifications may define the use of other opcodes with LLMNR.
+ LLMNR senders and responders MUST support standard queries (opcode
+ value of zero). LLMNR queries with unsupported OPCODE values MUST
+ be silently discarded by responders.
+
+
+TC TrunCation - specifies that this message was truncated due to
+ length greater than that permitted on the transmission channel.
+ The TC bit MUST NOT be set in an LLMNR query and if set is ignored
+ by an LLMNR responder. If the TC bit is set an LLMNR response,
+ then the sender MAY use the response if it contains all necessary
+ information, or the sender MAY discard the response and resend the
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 6]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+ LLMNR query over TCP using the unicast address of the responder as
+ the destination address. See [RFC2181] and Section 2.4 of this
+ specification for further discussion of the TC bit.
+
+
+Z Reserved for future use. Implementations of this specification
+ MUST set these bits to zero in both queries and responses. If
+ these bits are set in a LLMNR query or response, implementations of
+ this specification MUST ignore them. Since reserved bits could
+ conceivably be used for different purposes than in DNS,
+ implementors are advised not to enable processing of these bits in
+ an LLMNR implementation starting from a DNS code base.
+
+
+RCODE
+ Response code -- this 4 bit field is set as part of LLMNR
+ responses. In an LLMNR query, the RCODE MUST be zero, and is
+ ignored by the responder. The response to a multicast LLMNR query
+ MUST have RCODE set to zero. A sender MUST silently discard an
+ LLMNR response with a non-zero RCODE sent in response to a
+ multicast query.
+
+
+ If an LLMNR responder is authoritative for the name in a multicast
+ query, but an error is encountered, the responder SHOULD send an
+ LLMNR response with an RCODE of zero, no RRs in the answer section,
+ and the TC bit set. This will cause the query to be resent using
+ TCP, and allow the inclusion of a non-zero RCODE in the response to
+ the TCP query. Responding with the TC bit set is preferrable to
+ not sending a response, since it enables errors to be diagnosed.
+
+
+ Since LLMNR responders only respond to LLMNR queries for names for
+ which they are authoritative, LLMNR responders MUST NOT respond
+ with an RCODE of 3; instead, they should not respond at all.
+
+
+ LLMNR implementations MUST support EDNS0 [RFC2671] and extended
+ RCODE values.
+
+
+QDCOUNT
+ An unsigned 16 bit integer specifying the number of entries in the
+ question section. A sender MUST place only one question into the
+ question section of an LLMNR query. LLMNR responders MUST silently
+ discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
+ MUST silently discard LLMNR responses with QDCOUNT not equal to
+ one.
+
+
+ANCOUNT
+ An unsigned 16 bit integer specifying the number of resource
+ records in the answer section. LLMNR responders MUST silently
+ discard LLMNR queries with ANCOUNT not equal to zero.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 7]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+NSCOUNT
+ An unsigned 16 bit integer specifying the number of name server
+ resource records in the authority records section. Authority
+ record section processing is described in Section 2.9.
+
+
+ARCOUNT
+ An unsigned 16 bit integer specifying the number of resource
+ records in the additional records section. Additional record
+ section processing is described in Section 2.9.
+
+
+2.2. Sender behavior
+
+
+A sender may send an LLMNR query for any legal resource record type
+(e.g. A, AAAA, SRV, etc.) to the link-scope multicast address.
+
+
+As described in Section 2.4, a sender may also send a unicast query.
+Sections 2 and 3 describe the circumstances in which LLMNR queries may
+be sent.
+
+
+The sender MUST anticipate receiving no replies to some LLMNR queries,
+in the event that no responders are available within the link-scope or
+in the event no positive non-null responses exist for the transmitted
+query. If no positive response is received, a resolver treats it as a
+response that no records of the specified type and class exist for the
+specified name (it is treated the same as a response with RCODE=0 and an
+empty answer section).
+
+
+Since the responder may order the RRs in the response so as to indicate
+preference, the sender SHOULD preserve ordering in the response to the
+querying application.
+
+
+2.3. Responder behavior
+
+
+An LLMNR response MUST be sent to the sender via unicast.
+
+
+Upon configuring an IP address responders typically will synthesize
+corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR
+queries for these RRs. An SOA RR is synthesized only when a responder
+has another RR as well; the SOA RR MUST NOT be the only RR that a
+responder has. However, in general whether RRs are manually or
+automatically created is an implementation decision.
+
+
+For example, a host configured to have computer name "host1" and to be a
+member of the "example.com" domain, and with IPv4 address 10.1.1.1 and
+IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the
+following records:
+
+
+host1. IN A 10.1.1.1
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 8]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+
+host1.example.com. IN A 10.1.1.1
+IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+
+1.1.1.10.in-addr.arpa. IN PTR host1.
+IN PTR host1.example.com.
+
+
+6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
+IN PTR host1.
+IN PTR host1.example.com
+
+
+An LLMNR responder might be further manually configured with the name of
+a local mail server with an MX RR included in the "host1." and
+"host1.example.com." records.
+
+
+In responding to queries:
+
+
+[a] Responders MUST listen on UDP port TBD on the link-scope multicast
+ address(es) defined in Section 2, and on UDP and TCP port TBD on
+ the unicast address(es) that could be set as the source address(es)
+ when the responder responds to the LLMNR query.
+
+
+[b] Responders MUST direct responses to the port from which the query
+ was sent. When queries are received via TCP this is an inherent
+ part of the transport protocol. For queries received by UDP the
+ responder MUST take note of the source port and use that as the
+ destination port in the response. Responses SHOULD always be sent
+ from the port to which they were directed.
+
+
+[c] Responders MUST respond to LLMNR queries for names and addresses
+ they are authoritative for. This applies to both forward and
+ reverse lookups.
+
+
+[d] Responders MUST NOT respond to LLMNR queries for names they are not
+ authoritative for.
+
+
+[e] Responders MUST NOT respond using cached data.
+
+
+[f] If a DNS server is running on a host that supports LLMNR, the DNS
+ server MUST respond to LLMNR queries only for the RRSets relating
+ to the host on which the server is running, but MUST NOT respond
+ for other records for which the server is authoritative. DNS
+ servers also MUST NOT send LLMNR queries in order to resolve DNS
+ queries.
+
+
+[g] If a responder is authoritative for a name, it MAY respond with
+ RCODE=0 and an empty answer section, if the type of query does not
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 9]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+ match a RR that the responder has.
+
+
+As an example, a host configured to respond to LLMNR queries for the
+name "foo.example.com." is authoritative for the name
+"foo.example.com.". On receiving an LLMNR query for an A RR with the
+name "foo.example.com." the host authoritatively responds with A RR(s)
+that contain IP address(es) in the RDATA of the resource record. If the
+responder has a AAAA RR, but no A RR, and an A RR query is received, the
+responder would respond with RCODE=0 and an empty answer section.
+
+
+In conventional DNS terminology a DNS server authoritative for a zone is
+authoritative for all the domain names under the zone apex except for
+the branches delegated into separate zones. Contrary to conventional
+DNS terminology, an LLMNR responder is authoritative only for the zone
+apex.
+
+
+For example the host "foo.example.com." is not authoritative for the
+name "child.foo.example.com." unless the host is configured with
+multiple names, including "foo.example.com." and
+"child.foo.example.com.". As a result, "foo.example.com." cannot reply
+to an LLMNR query for "child.foo.example.com." with RCODE=3
+(authoritative name error). The purpose of limiting the name authority
+scope of a responder is to prevent complications that could be caused by
+coexistence of two or more hosts with the names representing child and
+parent (or grandparent) nodes in the DNS tree, for example,
+"foo.example.com." and "child.foo.example.com.".
+
+
+In this example (unless this limitation is introduced) an LLMNR query
+for an A resource record for the name "child.foo.example.com." would
+result in two authoritative responses: RCODE=3 (authoritative name
+error) received from "foo.example.com.", and a requested A record - from
+"child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
+hosts could perform a dynamic update of the parent (or grandparent) zone
+with a delegation to a child zone. In this example a host
+"child.foo.example.com." would send a dynamic update for the NS and glue
+A record to "foo.example.com.", but this approach significantly
+complicates implementation of LLMNR and would not be acceptable for
+lightweight hosts.
+
+
+2.4. Unicast queries and responses
+
+
+Unicast queries SHOULD be sent when:
+
+
+[a] A sender repeats a query after it received a response with the TC
+ bit set to the previous LLMNR multicast query, or
+
+
+[b] The sender queries for a PTR RR of a fully formed IP address within
+ the "in-addr.arpa" or "ip6.arpa" zones.
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 10]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+A responder receiving a unicast query MUST send the response with a
+source address set to the destination address field of the IP header of
+the query causing the response.
+
+
+Unicast LLMNR queries MUST be sent using TCP. Senders MUST support
+sending TCP queries, and responders MUST support listening for TCP
+queries.
+
+
+Responses to TCP unicast LLMNR queries MUST be sent using TCP, using
+the same connection as the query. If the sender of a TCP query receives
+a response to that query not using TCP, the response MUST be silently
+discarded.
+
+
+Unicast UDP queries MUST be silently discarded.
+
+
+If TCP connection setup cannot be completed in order to send a unicast
+TCP query, this is treated as a response that no records of the
+specified type and class exist for the specified name (it is treated the
+same as a response with RCODE=0 and an empty answer section).
+
+
+2.5. "Off link" detection
+
+
+For IPv4, an "on link" address is defined as a link-local address
+[IPv4Link] or an address whose prefix belongs to a subnet on the local
+link. For IPv6 [RFC2460] an "on link" address is either a link-local
+address, defined in [RFC2373], or an address whose prefix belongs to a
+subnet on the local link.
+
+
+A sender MUST select a source address for LLMNR queries that is "on
+link". The destination address of an LLMNR query MUST be a link-scope
+multicast address or an "on link" unicast address.
+
+
+A responder MUST select a source address for responses that is "on
+link". The destination address of an LLMNR response MUST be an "on link"
+unicast address.
+
+
+On receiving an LLMNR query, the responder MUST check whether it was
+sent to a LLMNR multicast addresses defined in Section 2. If it was
+sent to another multicast address, then the query MUST be silently
+discarded.
+
+
+Section 2.4 discusses use of TCP for LLMNR queries and responses. In
+composing an LLMNR query using TCP, the sender MUST set the Hop Limit
+field in the IPv6 header and the TTL field in the IPv4 header of the
+response to one (1). The responder SHOULD set the TTL or Hop Limit
+settings on the TCP listen socket to one (1) so that SYN-ACK packets
+will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents
+an incoming connection from off-link since the sender will not receive a
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 11]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+SYN-ACK from the responder.
+
+
+For UDP queries and responses the Hop Limit field in the IPv6 header,
+and the TTL field in the IPV4 header MAY be set to any value. However,
+it is RECOMMENDED that the value 255 be used for compatibility with
+Apple Rendezvous.
+
+
+Implementation note:
+
+
+ In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL
+ socket options are used to set the TTL of outgoing unicast and
+ multicast packets. The IP_RECVTTL socket option is available on some
+ platforms to retrieve the IPv4 TTL of received packets with
+ recvmsg(). [RFC2292] specifies similar options for setting and
+ retrieving the IPv6 Hop Limit.
+
+
+2.6. Responder responsibilities
+
+
+It is the responsibility of the responder to ensure that RRs returned in
+LLMNR responses MUST only include values that are valid on the local
+interface, such as IPv4 or IPv6 addresses valid on the local link or
+names defended using the mechanism described in Section 4. In
+particular:
+
+
+[a] If a link-scope IPv6 address is returned in a AAAA RR, that address
+ MUST be valid on the local link over which LLMNR is used.
+
+
+[b] If an IPv4 address is returned, it MUST be reachable through the
+ link over which LLMNR is used.
+
+
+[c] If a name is returned (for example in a CNAME, MX or SRV RR), the
+ name MUST be resolvable on the local link over which LLMNR is used.
+
+
+Routable addresses MUST be included first in the response, if available.
+This encourages use of routable address(es) for establishment of new
+connections.
+
+
+2.7. Retransmission and jitter
+
+
+An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
+when to retransmit an LLMNR query and how long to collect responses to
+an LLMNR query.
+
+
+If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
+then a sender MAY repeat the transmission of the query in order to
+assure that it was received by a host capable of responding to it.
+Retransmission of UDP queries SHOULD NOT be attempted more than 3 times.
+Where LLMNR queries are sent using TCP, retransmission is handled by the
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 12]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+transport layer.
+
+
+Because an LLMNR sender cannot know in advance if a query sent using
+multicast will receive no response, one response, or more than one
+response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect
+all possible responses, rather than considering the multicast query
+answered after the first response is received. A unicast query sender
+considers the query answered after the first response is received, so
+that it only waits for LLMNR_TIMEOUT if no response has been received.
+
+
+An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
+for each transmission. It is suggested that the computation of
+LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries
+sent on the same interface.
+
+
+For example, the algorithms described in RFC 2988 [RFC2988] (including
+exponential backoff) compute an RTO, which is used as the value of
+LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO
+(discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO
+(discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum
+RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
+
+
+Recommended values are an initial RTO of 1 second, a minimum RTO of
+200ms, and a maximum RTO of 5 seconds. In order to avoid
+synchronization, the transmission of each LLMNR query and response
+SHOULD delayed by a time randomly selected from the interval 0 to 100
+ms. This delay MAY be avoided by responders responding with RRs which
+they have previously determined to be UNIQUE (see Section 4 for
+details).
+
+
+2.8. DNS TTL
+
+
+The responder should use a pre-configured TTL value in the records
+returned an LLMNR response. A default value of 30 seconds is
+RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
+networks), the TTL value may need to be reduced.
+
+
+Due to the TTL minimalization necessary when caching an RRset, all TTLs
+in an RRset MUST be set to the same value.
+
+
+2.9. Use of the authority and additional sections
+
+
+Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
+concept of delegation. In LLMNR, the NS resource record type may be
+stored and queried for like any other type, but it has no special
+delegation semantics as it does in the DNS. Responders MAY have NS
+records associated with the names for which they are authoritative, but
+they SHOULD NOT include these NS records in the authority sections of
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 13]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+responses.
+
+
+Responders SHOULD insert an SOA record into the authority section of a
+negative response, to facilitate negative caching as specified in
+[RFC2308]. The owner name of this SOA record MUST be equal to the query
+name.
+
+
+Responders SHOULD NOT perform DNS additional section processing, except
+as required for EDNS0 and DNSSEC.
+
+
+Senders MUST NOT cache RRs from the authority or additional section of a
+response as answers, though they may be used for other purposes such as
+negative caching.
+
+
+3. Usage model
+
+
+Since LLMNR is a secondary name resolution mechanism, its usage is in
+part determined by the behavior of DNS implementations. This document
+does not specify any changes to DNS resolver behavior, such as
+searchlist processing or retransmission/failover policy. However,
+robust DNS resolver implementations are more likely to avoid unnecessary
+LLMNR queries.
+
+
+As noted in [DNSPerf], even when DNS servers are configured, a
+significant fraction of DNS queries do not receive a response, or result
+in negative responses due to missing inverse mappings or NS records that
+point to nonexistent or inappropriate hosts. This has the potential to
+result in a large number of unnecessary LLMNR queries.
+
+
+[RFC1536] describes common DNS implementation errors and fixes. If the
+proposed fixes are implemented, unnecessary LLMNR queries will be
+reduced substantially, and so implementation of [RFC1536] is
+recommended.
+
+
+For example, [RFC1536] Section 1 describes issues with retransmission
+and recommends implementation of a retransmission policy based on round
+trip estimates, with exponential backoff. [RFC1536] Section 4 describes
+issues with failover, and recommends that resolvers try another server
+when they don't receive a response to a query. These policies are
+likely to avoid unnecessary LLMNR queries.
+
+
+[RFC1536] Section 3 describes zero answer bugs, which if addressed will
+also reduce unnecessary LLMNR queries.
+
+
+[RFC1536] Section 6 describes name error bugs and recommended searchlist
+processing that will reduce unnecessary RCODE=3 (authoritative name)
+errors, thereby also reducing unnecessary LLMNR queries.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 14]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+3.1. LLMNR configuration
+
+
+Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
+possible for a dual stack host to be configured with the address of a
+DNS server over IPv4, while remaining unconfigured with a DNS server
+suitable for use over IPv6.
+
+
+In these situations, a dual stack host will send AAAA queries to the
+configured DNS server over IPv4. However, an IPv6-only host
+unconfigured with a DNS server suitable for use over IPv6 will be unable
+to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms
+(such as [RFC3315] and [DNSDisc]) are not yet widely deployed, and not
+all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration
+may be a common problem in the short term, and LLMNR may prove useful in
+enabling linklocal name resolution over IPv6.
+
+
+Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
+IPv6-only hosts may not be configured with a DNS server. Where there is
+no DNS server authoritative for the name of a host or the authoritative
+DNS server does not support dynamic client update over IPv6 or
+DHCPv6-based dynamic update, then an IPv6-only host will not be able to
+do DNS dynamic update, and other hosts will not be able to resolve its
+name.
+
+
+For example, if the configured DNS server responds to AAAA RR queries
+sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then
+it will not be possible to resolve the names of IPv6-only hosts. In
+this situation, LLMNR over IPv6 can be used for local name resolution.
+
+
+Similarly, if a DHCPv4 server is available providing DNS server
+configuration, and DNS server(s) exist which are authoritative for the A
+RRs of local hosts and support either dynamic client update over IPv4 or
+DHCPv4-based dynamic update, then the names of local IPv4 hosts can be
+resolved over IPv4 without LLMNR. However, if no DNS server is
+authoritative for the names of local hosts, or the authoritative DNS
+server(s) do not support dynamic update, then LLMNR enables linklocal
+name resolution over IPv4.
+
+
+Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
+configure LLMNR on an interface. The LLMNR Enable Option, described in
+[LLMNREnable], can be used to explicitly enable or disable use of LLMNR
+on an interface. The LLMNR Enable Option does not determine whether or
+in which order DNS itself is used for name resolution. The order in
+which various name resolution mechanisms should be used can be specified
+using the Name Service Search Option (NSSO) for DHCP [RFC2937], using
+the LLMNR Enable Option code carried in the NSSO data.
+
+
+It is possible that DNS configuration mechanisms will go in and out of
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 15]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+service. In these circumstances, it is possible for hosts within an
+administrative domain to be inconsistent in their DNS configuration.
+
+
+For example, where DHCP is used for configuring DNS servers, one or more
+DHCP servers can fail. As a result, hosts configured prior to the
+outage will be configured with a DNS server, while hosts configured
+after the outage will not. Alternatively, it is possible for the DNS
+configuration mechanism to continue functioning while configured DNS
+servers fail.
+
+
+Unless unconfigured hosts periodically retry configuration, an outage in
+the DNS configuration mechanism will result in hosts continuing to use
+LLMNR even once the outage is repaired. Since LLMNR only enables
+linklocal name resolution, this represents an unnecessary degradation in
+capabilities. As a result, it is recommended that hosts without a
+configured DNS server periodically attempt to obtain DNS configuration.
+For example, where DHCP is used for DNS configuration, [RFC2131]
+recommends a maximum retry interval of 64 seconds. In the absence of
+other guidance, a default retry interval of one (1) minute is
+RECOMMENDED.
+
+
+4. Conflict resolution
+
+
+The sender MUST anticipate receiving multiple replies to the same LLMNR
+query, in the event that several LLMNR enabled computers receive the
+query and respond with valid answers. When this occurs, the responses
+may first be concatenated, and then treated in the same manner that
+multiple RRs received from the same DNS server would; the sender
+perceives no inherent conflict in the receipt of multiple responses.
+
+
+There are some scenarios when multiple responders MAY respond to the
+same query. There are other scenarios when only one responder MAY
+respond to a query. Resource records for which the latter queries are
+submitted are referred as UNIQUE throughout this document. The
+uniqueness of a resource record depends on a nature of the name in the
+query and type of the query. For example it is expected that:
+
+
+ - multiple hosts may respond to a query for an SRV type record
+ - multiple hosts may respond to a query for an A or AAAA type
+ record for a cluster name (assigned to multiple hosts in
+ the cluster)
+ - only a single host may respond to a query for an A or AAAA
+ type record for a name.
+
+
+Every responder that responds to an LLMNR query AND includes a UNIQUE
+record in the response:
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 16]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+[1] MUST verify that there is no other host within the scope of the
+ LLMNR query propagation that can return a resource record for the
+ same name, type and class.
+
+
+[2] MUST NOT include a UNIQUE resource record in the response without
+ having verified its uniqueness.
+
+
+Where a host is configured to issue LLMNR queries on more than one
+interface, each interface should have its own independent LLMNR cache.
+For each UNIQUE resource record in a given interface's configuration,
+the host MUST verify resource record uniqueness on that interface. To
+accomplish this, the host MUST send an LLMNR query for each UNIQUE
+resource record.
+
+
+By default, a host SHOULD be configured to behave as though all RRs are
+UNIQUE. Uniqueness verification is carried out when the host:
+
+
+ - starts up or is rebooted
+ - wakes from sleep (if the network interface was inactive during sleep)
+ - is configured to respond to the LLMNR queries on an interface
+ enabled for transmission and reception of IP traffic
+ - is configured to respond to the LLMNR queries using additional
+ UNIQUE resource records
+ - detects that an interface is connected and is usable
+ (e.g. an IEEE 802 hardware link-state change indicating
+ that a cable was attached or completion of authentication
+ (and if needed, association) with a wireless base station
+ or adhoc network
+
+
+When a host that has a UNIQUE record receives an LLMNR query for that
+record, the host MUST respond. After the client receives a response, it
+MUST check whether the response arrived on an interface different from
+the one on which the query was sent. If the response arrives on a
+different interface, the client can use the UNIQUE resource record in
+response to LLMNR queries. If not, then it MUST NOT use the UNIQUE
+resource record in response to LLMNR queries.
+
+
+The name conflict detection mechanism doesn't prevent name conflicts
+when previously partitioned segments are connected by a bridge. In order
+to minimize the chance of conflicts in such a situation, it is
+recommended that steps be taken to ensure name uniqueness. For example,
+the name could be chosen randomly from a large pool of potential names,
+or the name could be assigned via a process designed to guarantee
+uniqueness.
+
+
+When name conflicts are detected, they SHOULD be logged. To detect
+duplicate use of a name, an administrator can use a name resolution
+utility which employs LLMNR and lists both responses and responders.
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 17]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+This would allow an administrator to diagnose behavior and potentially
+to intervene and reconfigure LLMNR responders who should not be
+configured to respond to the same name.
+
+
+4.1. Considerations for Multiple Interfaces
+
+
+A multi-homed host may elect to configure LLMNR on only one of its
+active interfaces. In many situations this will be adequate. However,
+should a host need to configure LLMNR on more than one of its active
+interfaces, there are some additional precautions it MUST take.
+Implementers who are not planning to support LLMNR on multiple
+interfaces simultaneously may skip this section.
+
+
+A multi-homed host checks the uniqueness of UNIQUE records as described
+in Section 4. The situation is illustrated in figure 1.
+
+
+ ---------- ----------
+ | | | |
+ [A] [myhost] [myhost]
+
+
+ Figure 1. Link-scope name conflict
+
+
+In this situation, the multi-homed myhost will probe for, and defend,
+its host name on both interfaces. A conflict will be detected on one
+interface, but not the other. The multi-homed myhost will not be able
+to respond with a host RR for "myhost" on the interface on the right
+(see Figure 1). The multi-homed host may, however, be configured to use
+the "myhost" name on the interface on the left.
+
+
+Since names are only unique per-link, hosts on different links could be
+using the same name. If an LLMNR client sends requests over multiple
+interfaces, and receives replies from more than one, the result returned
+to the client is defined by the implementation. The situation is
+illustrated in figure 2.
+
+
+ ---------- ----------
+ | | | |
+ [A] [myhost] [A]
+
+
+
+ Figure 2. Off-segment name conflict
+
+
+If host myhost is configured to use LLMNR on both interfaces, it will
+send LLMNR queries on both interfaces. When host myhost sends a query
+for the host RR for name "A" it will receive a response from hosts on
+both interfaces.
+
+
+Host myhost cannot distinguish between the situation shown in Figure 2,
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 18]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+and that shown in Figure 3 where no conflict exists.
+
+
+ [A]
+ | |
+ ----- -----
+ | |
+ [myhost]
+
+
+ Figure 3. Multiple paths to same host
+
+
+This illustrates that the proposed name conflict resolution mechanism
+does not support detection or resolution of conflicts between hosts on
+different links. This problem can also occur with unicast DNS when a
+multi-homed host is connected to two different networks with separated
+name spaces. It is not the intent of this document to address the issue
+of uniqueness of names within DNS.
+
+
+4.2. API issues
+
+
+[RFC2553] provides an API which can partially solve the name ambiguity
+problem for applications written to use this API, since the sockaddr_in6
+structure exposes the scope within which each scoped address exists, and
+this structure can be used for both IPv4 (using v4-mapped IPv6
+addresses) and IPv6 addresses.
+
+
+Following the example in Figure 2, an application on 'myhost' issues the
+request getaddrinfo("A", ...) with ai_family=AF_INET6 and
+ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
+interfaces and the resolver library will return a list containing
+multiple addrinfo structures, each with an associated sockaddr_in6
+structure. This list will thus contain the IPv4 and IPv6 addresses of
+both hosts responding to the name 'A'. Link-local addresses will have a
+sin6_scope_id value that disambiguates which interface is used to reach
+the address. Of course, to the application, Figures 2 and 3 are still
+indistinguishable, but this API allows the application to communicate
+successfully with any address in the list.
+
+
+5. Security Considerations
+
+
+LLMNR is by nature a peer-to-peer name resolution protocol. It is
+therefore inherently more vulnerable than DNS, since existing DNS
+security mechanisms are difficult to apply to LLMNR. While tools exist
+to alllow an attacker to spoof a response to a DNS query, spoofing a
+response to an LLMNR query is easier since the query is sent to a link-
+scope multicast address, where every host on the logical link will be
+made aware of it.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 19]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+In order to address the security vulnerabilities, the following
+mechanisms are contemplated:
+
+
+[1] Scope restrictions.
+
+
+[2] Usage restrictions.
+
+
+[3] Cache and port separation.
+
+
+[4] Authentication.
+
+
+These techniques are described in the following sections.
+
+
+5.1. Scope restriction
+
+
+With LLMNR it is possible that hosts will allocate conflicting names for
+a period of time, or that attackers will attempt to deny service to
+other hosts by allocating the same name. Such attacks also allow hosts
+to receive packets destined for other hosts.
+
+
+Since LLMNR is typically deployed in situations where no trust model can
+be assumed, it is likely that LLMNR queries and responses will be
+unauthenticated. In the absence of authentication, LLMNR reduces the
+exposure to such threats by utilizing UDP queries sent to a link-scope
+multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)
+fields to one (1) on TCP queries and responses.
+
+
+Using a TTL of one (1) to set up a TCP connection in order to send a
+unicast LLMNR query reduces the likelihood of both denial of service
+attacks and spoofed responses. Checking that an LLMNR query is sent to
+a link-scope multicast address should prevent spoofing of multicast
+queries by off-link attackers.
+
+
+While this limits the ability of off-link attackers to spoof LLMNR
+queries and responses, it does not eliminate it. For example, it is
+possible for an attacker to spoof a response to a frequent query (such
+as an A or AAAA query for a popular Internet host), and by using a TTL
+or Hop Limit field larger than one (1), for the forged response to reach
+the LLMNR sender.
+
+
+When LLMNR queries are sent to a link-scope multicast address, it is
+possible that some routers may not properly implement link-scope
+multicast, or that link-scope multicast addresses may leak into the
+multicast routing system.
+
+
+Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one
+in an LLMNR UDP response may enable denial of service attacks across the
+Internet. However, since LLMNR responders only respond to queries for
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 20]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+which they are authoritative, and LLMNR does not provide wildcard query
+support, it is believed that this threat is minimal.
+
+
+There also are scenarios such as public "hotspots" where attackers can
+be present on the same link. These threats are most serious in wireless
+networks such as 802.11, since attackers on a wired network will require
+physical access to the home network, while wireless attackers may reside
+outside the home. Link-layer security can be of assistance against
+these threats if it is available.
+
+
+5.2. Usage restriction
+
+
+As noted in Sections 2 and 3, LLMNR is intended for usage in a limited
+set of scenarios.
+
+
+If an LLMNR query is sent whenever a DNS server does not respond in a
+timely way, then an attacker can poison the LLMNR cache by responding to
+the query with incorrect information. To some extent, these
+vulnerabilities exist today, since DNS response spoofing tools are
+available that can allow an attacker to respond to a query more quickly
+than a distant DNS server.
+
+
+Since LLMNR queries are sent and responded to on the local-link, an
+attacker will need to respond more quickly to provide its own response
+prior to arrival of the response from a legitimate responder. If an
+LLMNR query is sent for an off-link host, spoofing a response in a
+timely way is not difficult, since a legitimate response will never be
+received.
+
+
+The vulnerability is more serious if LLMNR is given higher priority than
+DNS among the enabled name resolution mechanisms. In such a
+configuration, a denial of service attack on the DNS server would not be
+necessary in order to poison the LLMNR cache, since LLMNR queries would
+be sent even when the DNS server is available. In addition, the LLMNR
+cache, once poisoned, would take precedence over the DNS cache,
+eliminating the benefits of cache separation. As a result, LLMNR is only
+used as a name resolution mechanism of last resort.
+
+
+5.3. Cache and port separation
+
+
+In order to prevent responses to LLMNR queries from polluting the DNS
+cache, LLMNR implementations MUST use a distinct, isolated cache for
+LLMNR on each interface. The use of separate caches is most effective
+when LLMNR is used as a name resolution mechanism of last resort, since
+this minimizes the opportunities for poisoning the LLMNR cache, and
+decreases reliance on it.
+
+
+LLMNR operates on a separate port from DNS, reducing the likelihood that
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 21]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+a DNS server will unintentionally respond to an LLMNR query.
+
+
+5.4. Authentication
+
+
+LLMNR implementations may not support DNSSEC or TSIG, and as a result,
+responses to LLMNR queries may be unauthenticated. If authentication is
+desired, and a pre-arranged security configuration is possible, then
+IPsec ESP with a null-transform MAY be used to authenticate LLMNR
+responses. In a small network without a certificate authority, this can
+be most easily accomplished through configuration of a group pre-shared
+key for trusted hosts.
+
+
+6. IANA Considerations
+
+
+This specification creates one new name space: the reserved bits in the
+LLMNR header. These are allocated by IETF Consensus, in accordance with
+BCP 26 [RFC2434].
+
+
+LLMNR requires allocation of a port TBD for both TCP and UDP.
+Assignment of the same port for both transports is requested.
+
+
+LLMNR requires allocation of a link-scope multicast IPv4 address TBD.
+LLMNR also requires allocation of a link-scope multicast IPv6 address
+TBD.
+
+
+7. References
+
+
+7.1. Normative References
+
+
+[RFC1035] Mockapetris, P., "Domain Names - Implementation and
+ Specification", RFC 1035, November 1987.
+
+
+[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992.
+
+
+[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+
+[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+ RFC 2308, March 1998.
+
+
+[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
+ 2365, July 1998.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 22]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+
+[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October
+ 1998.
+
+
+[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+
+[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+
+[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
+ August 1999.
+
+
+[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
+ Timer", RFC 2988, November 2000.
+
+
+7.2. Informative References
+
+
+[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
+ Fixes", RFC 1536, October 1993.
+
+
+[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+
+[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+ Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+ April 1997.
+
+
+[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
+ RFC 2292, February 1998.
+
+
+[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
+ Socket Interface Extensions for IPv6", RFC 2553, March 1999.
+
+
+[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
+ 2937, September 2000.
+
+
+[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
+ IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+
+[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
+ Caching", IEEE/ACM Transactions on Networking, Volume 10,
+ Number 5, pp. 589, October 2002.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 23]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
+ unicast addresses to communicate with recursive DNS servers",
+ Internet draft (work in progress), draft-ietf-ipv6-dns-
+ discovery-07.txt, October 2002.
+
+
+[IPV4Link]
+ Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
+ of IPv4 Link-Local Addresses", Internet draft (work in
+ progress), draft-ietf-zeroconf-ipv4-linklocal-14.txt, April
+ 2004.
+
+
+[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
+ Portable Operating System Interface (POSIX). Open Group
+ Technical Standard: Base Specifications, Issue 6, December
+ 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
+
+
+[LLMNREnable]
+ Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
+ in progress), draft-guttman-mdns-enable-02.txt, April 2002.
+
+
+[NodeInfo]
+ Crawford, M., "IPv6 Node Information Queries", Internet draft
+ (work in progress), draft-ietf-ipn-gwg-icmp-name-
+ lookups-09.txt, May 2002.
+
+
+Acknowledgments
+
+
+This work builds upon original work done on multicast DNS by Bill
+Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
+grant #F30602-99-1-0523. The authors gratefully acknowledge their
+contribution to the current specification. Constructive input has also
+been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert
+Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron
+Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van-
+Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku
+Savela.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 24]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 2004
+
+
+
+Authors' Addresses
+
+
+Levon Esibov
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052
+
+
+EMail: levone@microsoft.com
+
+
+Bernard Aboba
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052
+
+
+Phone: +1 425 706 6605
+EMail: bernarda@microsoft.com
+
+
+Dave Thaler
+Microsoft Corporation
+One Microsoft Way
+Redmond, WA 98052
+
+
+Phone: +1 425 703 8835
+EMail: dthaler@microsoft.com
+
+
+Intellectual Property Statement
+
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property or other rights that might be claimed to pertain
+to the implementation or use of the technology described in this
+document or the extent to which any license under such rights might or
+might not be available; neither does it represent that it has made any
+effort to identify any such rights. Information on the IETF's
+procedures with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims of
+rights made available for publication and any assurances of licenses to
+be made available, or the result of an attempt made to obtain a general
+license or permission for the use of such proprietary rights by
+implementors or users of this specification can be obtained from the
+IETF Secretariat.
+
+
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary rights
+which may cover technology that may be required to practice this
+standard. Please address the information to the IETF Executive
+Director.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 25]
+
+
+
+
+
+
+INTERNET-DRAFT LLMNR 17 March 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.
+
+
+Open Issues
+
+
+Open issues with this specification are tracked on the following web
+site:
+
+
+http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
+
+
+Expiration Date
+
+
+This memo is filed as <draft-ietf-dnsext-mdns-30.txt>, and expires
+October 4, 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 26]
\ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-nsec-rdata-05.txt b/doc/draft/draft-ietf-dnsext-nsec-rdata-05.txt deleted file mode 100644 index acdf4581..00000000 --- a/doc/draft/draft-ietf-dnsext-nsec-rdata-05.txt +++ /dev/null @@ -1,503 +0,0 @@ - - -DNS Extensions Working Group J. Schlyter, Ed. -Internet-Draft March 11, 2004 -Updates: RFC 2535, RFC TCR -Expires: September 9, 2004 - - - DNSSEC NSEC RDATA Format - draft-ietf-dnsext-nsec-rdata-05.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 September 9, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document redefines the wire format of the "Type Bit Map" field - in the NSEC resource record RDATA format to cover the full RR type - space. - - - - - - - - - - - -Schlyter Expires September 9, 2004 [Page 1] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3 - 2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4 - 2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4 - 2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4 - 2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5 - 2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5 - 2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 6 - 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 - 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 - Normative References . . . . . . . . . . . . . . . . . . . . 6 - Informational References . . . . . . . . . . . . . . . . . . 7 - Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 - A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 - Intellectual Property and Copyright Statements . . . . . . . 8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires September 9, 2004 [Page 2] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - -1. Introduction - - The NSEC [6] Resource Record (RR) is used for authenticated proof of - the non-existence of DNS owner names and types. The NSEC RR is based - on the NXT RR as described in RFC 2535 [3], and is similar except for - the name and typecode. The RDATA format for the NXT RR had a - limitation in that, without using a yet undefined extension - mechanism, the the RDATA could only carry information about the - existence of the first 127 types. - - To prevent the introduction of an extension mechanism into a deployed - base of DNSSEC aware servers and resolvers, once the first 127 type - codes are allocated, this document redefines the wire format of the - "Type Bit Map" field in the NSEC RDATA to cover the full RR type - space. - - This document introduces a new format for the type bit map. The - properties of the type bit map format are that it can cover the full - possible range of typecodes, that it is relatively economic in the - amount of space it uses for the common case of a few types with an - owner name, that it can represent owner names with all possible types - present in packets of approximately 8.5 kilobytes and that the - representation is simple to implement. Efficient searching of the - type bitmap for the presence of certain types is not a requirement. - - For convenience and completeness this document presents the syntax - and semantics for the NSEC RR based on the specification in RFC 2535 - [3] and as updated by RFC TCR [6], thereby not introducing changes - except for the syntax of the type bit map. - - This document updates RFC 2535 [3] and RFC TCR [6]. - - 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 [1]. - -2. The NSEC Resource Record - - The NSEC resource record lists two separate things: the owner name of - the next RRset in the canonical ordering of the zone, and the set of - RR types present at the NSEC RR's owner name. The complete set of - NSEC RRs in a zone both indicate which RRsets exist in a zone and - also form a chain of owner names in the zone. This information is - used to provide authenticated denial of existence for DNS data, as - described in RFC 2535 [3]. - - The type value for the NSEC RR is 47. - - - - -Schlyter Expires September 9, 2004 [Page 3] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - - The NSEC RR RDATA format is class independent and defined for all - classes. - - The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [2]. - -2.1 NSEC RDATA Wire Format - - The RDATA of the NSEC RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Domain Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / List of Type Bit Map(s) / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -2.1.1 The Next Domain Name Field - - The Next Domain Name field contains the owner name of the next RR in - the canonical ordering of the zone. The value of the Next Domain - Name field in the last NSEC record in the zone is the name of the - zone apex (the owner name of the zone's SOA RR). - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. A receiver which receives an - NSEC RR containing a compressed Next Domain Name field SHOULD - decompress the field value. - - Owner names of RRsets not authoritative for the given zone (such as - glue records) MUST NOT be listed in the Next Domain Name unless at - least one authoritative RRset exists at the same owner name. - -2.1.2 The List of Type Bit Map(s) Field - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that has - at least one active RR type is encoded using a single octet window - number (from 0 to 255), a single octet bitmap length (from 1 to 32) - indicating the number of octets used for the window block's bitmap, - and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC RR RDATA in increasing numerical - order. - - "|" denotes concatenation - - - -Schlyter Expires September 9, 2004 [Page 4] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - - Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRset of that type is present for the NSEC - RR's owner name. If a bit is set to 0, it indicates that no RRset of - that type is present for the NSEC RR's owner name. - - Since bit 0 in window block 0 refers to the non-existing RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4] - (section 3.1) or within the range reserved for assignment only to - QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in - zone data. If encountered, they must be ignored upon reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC RR's owner name. Trailing zero octets not specified MUST be - interpretted as zero octets. - -2.1.3 Inclusion of Wildcard Names in NSEC RDATA - - If a wildcard owner name appears in a zone, the wildcard label ("*") - is treated as a literal symbol and is treated the same as any other - owner name for purposes of generating NSEC RRs. Wildcard owner names - appear in the Next Domain Name field without any wildcard expansion. - RFC 2535 [3] describes the impact of wildcards on authenticated - denial of existence. - -2.2 The NSEC RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - The List of Type Bit Map(s) Field is represented as a sequence of RR - type mnemonics. When the mnemonic is not known, the TYPE - representation as described in RFC 3597 [5] (section 5) MUST be used. - - - - - - -Schlyter Expires September 9, 2004 [Page 5] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - -2.3 NSEC RR Example - - The following NSEC RR identifies the RRsets associated with - alfa.example.com. and identifies the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234 - - The first four text fields specify the name, TTL, Class, and RR type - (NSEC). The entry host.example.com. is the next authoritative name - after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC - and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC and - TYPE1234 RRsets associated with the name alfa.example.com. - - The RDATA section of the NSEC RR above would be encoded as: - - 0x04 'h' 'o' 's' 't' - 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' - 0x03 'c' 'o' 'm' 0x00 - 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 - 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x20 - - Assuming that the resolver can authenticate this NSEC record, it - could be used to prove that beta.example.com does not exist, or could - be used to prove there is no AAAA record associated with - alfa.example.com. Authenticated denial of existence is discussed in - RFC 2535 [3]. - -3. IANA Considerations - - This document introduces no new IANA considerations, because all of - the protocol parameters used in this document have already been - assigned by RFC TCR [6]. - -4. Security Considerations - - The update of the RDATA format and encoding does not affect the - security of the use of NSEC RRs. - -Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC - - - -Schlyter Expires September 9, 2004 [Page 6] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - - 2308, March 1998. - - [3] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [4] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name - System (DNS) IANA Considerations", BCP 42, RFC 2929, September - 2000. - - [5] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) - Types", RFC 3597, September 2003. - - [6] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work - in progress), October 2003. - -Informational References - - [7] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [8] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - -Author's Address - - Jakob Schlyter (editor) - Karl Gustavsgatan 15 - Goteborg SE-411 25 - Sweden - - EMail: jakob@schlyter.se - -Appendix A. Acknowledgements - - The encoding described in this document was initially proposed by - Mark Andrews. Other encodings where proposed by David Blacka and - Michael Graff. - - - - - - - - - - - - -Schlyter Expires September 9, 2004 [Page 7] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Schlyter Expires September 9, 2004 [Page 8] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires September 9, 2004 [Page 9] - diff --git a/doc/draft/draft-ietf-dnsext-nsec-rdata-06.txt b/doc/draft/draft-ietf-dnsext-nsec-rdata-06.txt new file mode 100644 index 00000000..c8904456 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-nsec-rdata-06.txt @@ -0,0 +1,504 @@ +
+DNS Extensions Working Group J. Schlyter, Ed.
+Internet-Draft May 10, 2004
+Updates: RFC 2535, RFC TCR (if approved)
+Expires: November 8, 2004
+
+
+ DNSSEC NSEC RDATA Format
+ draft-ietf-dnsext-nsec-rdata-06.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 November 8, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document redefines the wire format of the "Type Bit Map" field
+ in the NSEC resource record RDATA format to cover the full RR type
+ space.
+
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires November 8, 2004 [Page 1]
+
+Internet-Draft DNSSEC NSEC RDATA Format May 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3
+ 2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4
+ 2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4
+ 2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4
+ 2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5
+ 2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5
+ 2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . 6
+ Normative References . . . . . . . . . . . . . . . . . . . . 6
+ Informational References . . . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
+ A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
+ Intellectual Property and Copyright Statements . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires November 8, 2004 [Page 2]
+
+Internet-Draft DNSSEC NSEC RDATA Format May 2004
+
+
+1. Introduction
+
+ The NSEC [5] Resource Record (RR) is used for authenticated proof of
+ the non-existence of DNS owner names and types. The NSEC RR is based
+ on the NXT RR as described in RFC 2535 [2], and is similar except for
+ the name and typecode. The RDATA format for the NXT RR has the
+ limitation in that the RDATA could only carry information about the
+ existence of the first 127 types. RFC 2535 did reserve a bit to
+ specify an extension mechanism, but the mechanism was never actually
+ defined.
+
+ In order to avoid the need to develop an extension mechanism into a
+ deployed base of DNSSEC aware servers and resolvers once the first
+ 127 type codes are allocated, this document redefines the wire format
+ of the "Type Bit Map" field in the NSEC RDATA to cover the full RR
+ type space.
+
+ This document introduces a new format for the type bit map. The
+ properties of the type bit map format are that it can cover the full
+ possible range of typecodes, that it is relatively economical in the
+ amount of space it uses for the common case of a few types with an
+ owner name, that it can represent owner names with all possible types
+ present in packets of approximately 8.5 kilobytes and that the
+ representation is simple to implement. Efficient searching of the
+ type bitmap for the presence of certain types is not a requirement.
+
+ For convenience and completeness this document presents the syntax
+ and semantics for the NSEC RR based on the specification in RFC 2535
+ [2] and as updated by RFC TCR [5], thereby not introducing changes
+ except for the syntax of the type bit map.
+
+ This document updates RFC 2535 [2] and RFC TCR [5].
+
+ 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 [1].
+
+2. The NSEC Resource Record
+
+ The NSEC resource record lists two separate things: the owner name of
+ the next RRset in the canonical ordering of the zone, and the set of
+ RR types present at the NSEC RR's owner name. The complete set of
+ NSEC RRs in a zone both indicate which RRsets exist in a zone and
+ also form a chain of owner names in the zone. This information is
+ used to provide authenticated denial of existence for DNS data, as
+ described in RFC 2535 [2].
+
+ The type value for the NSEC RR is 47.
+
+
+
+Schlyter Expires November 8, 2004 [Page 3]
+
+Internet-Draft DNSSEC NSEC RDATA Format May 2004
+
+
+ The NSEC RR RDATA format is class independent and defined for all
+ classes.
+
+ The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
+ field. This is in the spirit of negative caching [8].
+
+2.1 NSEC RDATA Wire Format
+
+ The RDATA of the NSEC RR is as shown below:
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Next Domain Name /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / List of Type Bit Map(s) /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+2.1.1 The Next Domain Name Field
+
+ The Next Domain Name field contains the owner name of the next RR in
+ the canonical ordering of the zone. The value of the Next Domain
+ Name field in the last NSEC record in the zone is the name of the
+ zone apex (the owner name of the zone's SOA RR).
+
+ A sender MUST NOT use DNS name compression on the Next Domain Name
+ field when transmitting an NSEC RR.
+
+ Owner names of RRsets not authoritative for the given zone (such as
+ glue records) MUST NOT be listed in the Next Domain Name unless at
+ least one authoritative RRset exists at the same owner name.
+
+2.1.2 The List of Type Bit Map(s) Field
+
+ The RR type space is split into 256 window blocks, each representing
+ the low-order 8 bits of the 16-bit RR type space. Each block that has
+ at least one active RR type is encoded using a single octet window
+ number (from 0 to 255), a single octet bitmap length (from 1 to 32)
+ indicating the number of octets used for the window block's bitmap,
+ and up to 32 octets (256 bits) of bitmap.
+
+ Window blocks are present in the NSEC RR RDATA in increasing
+ numerical order.
+
+ "|" denotes concatenation
+
+ Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
+
+
+
+Schlyter Expires November 8, 2004 [Page 4]
+
+Internet-Draft DNSSEC NSEC RDATA Format May 2004
+
+
+ Each bitmap encodes the low-order 8 bits of RR types within the
+ window block, in network bit order. The first bit is bit 0. For
+ window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+ to RR type 2 (NS), and so forth. For window block 1, bit 1
+ corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
+ 1, it indicates that an RRset of that type is present for the NSEC
+ RR's owner name. If a bit is set to 0, it indicates that no RRset of
+ that type is present for the NSEC RR's owner name.
+
+ Since bit 0 in window block 0 refers to the non-existing RR type 0,
+ it MUST be set to 0. After verification, the validator MUST ignore
+ the value of bit 0 in window block 0.
+
+ Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [3]
+ (section 3.1) or within the range reserved for assignment only to
+ QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
+ zone data. If encountered, they must be ignored upon reading.
+
+ Blocks with no types present MUST NOT be included. Trailing zero
+ octets in the bitmap MUST be omitted. The length of each block's
+ bitmap is determined by the type code with the largest numerical
+ value, within that block, among the set of RR types present at the
+ NSEC RR's owner name. Trailing zero octets not specified MUST be
+ interpretted as zero octets.
+
+2.1.3 Inclusion of Wildcard Names in NSEC RDATA
+
+ If a wildcard owner name appears in a zone, the wildcard label ("*")
+ is treated as a literal symbol and is treated the same as any other
+ owner name for purposes of generating NSEC RRs. Wildcard owner names
+ appear in the Next Domain Name field without any wildcard expansion.
+ RFC 2535 [2] describes the impact of wildcards on authenticated
+ denial of existence.
+
+2.2 The NSEC RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Next Domain Name field is represented as a domain name.
+
+ The List of Type Bit Map(s) Field is represented as a sequence of RR
+ type mnemonics. When the mnemonic is not known, the TYPE
+ representation as described in RFC 3597 [4] (section 5) MUST be used.
+
+2.3 NSEC RR Example
+
+ The following NSEC RR identifies the RRsets associated with
+ alfa.example.com. and identifies the next authoritative name after
+
+
+
+Schlyter Expires November 8, 2004 [Page 5]
+
+Internet-Draft DNSSEC NSEC RDATA Format May 2004
+
+
+ alfa.example.com.
+
+ alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234
+
+ The first four text fields specify the name, TTL, Class, and RR type
+ (NSEC). The entry host.example.com. is the next authoritative name
+ after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC
+ and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC and
+ TYPE1234 RRsets associated with the name alfa.example.com.
+
+ The RDATA section of the NSEC RR above would be encoded as:
+
+ 0x04 'h' 'o' 's' 't'
+ 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
+ 0x03 'c' 'o' 'm' 0x00
+ 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
+ 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x20
+
+ Assuming that the resolver can authenticate this NSEC record, it
+ could be used to prove that beta.example.com does not exist, or could
+ be used to prove there is no AAAA record associated with
+ alfa.example.com. Authenticated denial of existence is discussed in
+ RFC 2535 [2].
+
+3. IANA Considerations
+
+ This document introduces no new IANA considerations, because all of
+ the protocol parameters used in this document have already been
+ assigned by RFC TCR [5].
+
+4. Security Considerations
+
+ The update of the RDATA format and encoding does not affect the
+ security of the use of NSEC RRs.
+
+Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [3] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name
+ System (DNS) IANA Considerations", BCP 42, RFC 2929, September
+
+
+
+Schlyter Expires November 8, 2004 [Page 6]
+
+Internet-Draft DNSSEC NSEC RDATA Format May 2004
+
+
+ 2000.
+
+ [4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+ Types", RFC 3597, September 2003.
+
+ [5] Weiler, S., "Legacy Resolver Compatibility for Delegation
+ Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
+ in progress), October 2003.
+
+Informational References
+
+ [6] Mockapetris, P., "Domain names - concepts and facilities", STD
+ 13, RFC 1034, November 1987.
+
+ [7] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
+ 2308, March 1998.
+
+
+Author's Address
+
+ Jakob Schlyter (editor)
+ Karl Gustavsgatan 15
+ Goteborg SE-411 25
+ Sweden
+
+ EMail: jakob@schlyter.se
+
+Appendix A. Acknowledgements
+
+ The encoding described in this document was initially proposed by
+ Mark Andrews. Other encodings where proposed by David Blacka and
+ Michael Graff.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires November 8, 2004 [Page 7]
+
+Internet-Draft DNSSEC NSEC RDATA Format May 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Schlyter Expires November 8, 2004 [Page 8]
+
+Internet-Draft DNSSEC NSEC RDATA Format May 2004
+
+
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires November 8, 2004 [Page 9]
+
+
+
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.txt deleted file mode 100644 index 04addcfb..00000000 --- a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.txt +++ /dev/null @@ -1,1288 +0,0 @@ - - -DNSOP O. Kolkman -Internet-Draft RIPE NCC -Expires: March 1, 2004 R. Gieben - NLnet Labs - September 2003 - - - DNSSEC Operational Practices - draft-ietf-dnsop-dnssec-operational-practices-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 March 1, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document intends to describe a set of practices for operating a - DNSSEC aware enviroment. Its target audience is zone administrators - who are deploying DNSSEC and need a guide to help them chose sensible - values for DNSSEC parameters. Is also discusses operational matters - like key rollovers, KSK and ZSK considerations and more. - - - - - - - - - -Kolkman & Gieben Expires March 1, 2004 [Page 1] - -Internet-Draft DNSSEC Operational Practices September 2003 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 The use of the term 'key' . . . . . . . . . . . . . . . . . 3 - 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.1 Time definitions . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2 Time considerations . . . . . . . . . . . . . . . . . . . . 4 - 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1 Motivations for the KSK and ZSK functions . . . . . . . . . 6 - 3.2 Key security considerations . . . . . . . . . . . . . . . . 7 - 3.3 Key rollovers . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.3.1 Zone-signing key rollovers . . . . . . . . . . . . . . . . . 9 - 3.3.2 Key-signing key rollovers . . . . . . . . . . . . . . . . . 12 - 4. Planning for emergency key rollover. . . . . . . . . . . . . 13 - 4.1 KSK compromise . . . . . . . . . . . . . . . . . . . . . . . 13 - 4.2 ZSK compromise . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.3 Compromises of keys anchored in resolvers . . . . . . . . . 14 - 5. Parental policies. . . . . . . . . . . . . . . . . . . . . . 14 - 5.1 Initial key exchanges and parental policies - considerations. . . . . . . . . . . . . . . . . . . . . . . 14 - 5.2 Storing keys so hashes can be regenerated . . . . . . . . . 15 - 5.3 Security lameness checks. . . . . . . . . . . . . . . . . . 15 - 5.4 SIG DS validity period. . . . . . . . . . . . . . . . . . . 15 - 6. Security considerations . . . . . . . . . . . . . . . . . . 16 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 - Normative References . . . . . . . . . . . . . . . . . . . . 16 - Informative References . . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 - A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 17 - B. Zone-signing key rollover howto . . . . . . . . . . . . . . 18 - C. Typographic conventions . . . . . . . . . . . . . . . . . . 19 - D. Document Details and Changes . . . . . . . . . . . . . . . . 20 - D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . . 21 - Intellectual Property and Copyright Statements . . . . . . . 22 - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires March 1, 2004 [Page 2] - -Internet-Draft DNSSEC Operational Practices September 2003 - - -1. Introduction - - During workshops and early operational deployment tests, operators - and system administrators gained knowledge about operating DNSSEC - aware DNS services. This document describes these practices. - - The structure of the document is as follows. It starts with - discussing some of the considerations with respect to timing - parameters of DNS in relation to DNSSEC (Section 2). Aspects of key - management such as key rollover schemes are described in Section 3. - Emergency rollover considerations are addressed in Section 4. The - Typographic conventions used in this document are explained in - Appendix C. - - Since this is a document with operational suggestions and there is no - protocol specifications the RFC2119 [5] language does not apply. - -1.1 The use of the term 'key' - - It is assumed that the reader is familiar with the concept of - asymmetric keys on which DNSSEC is based. Therefore this document - will use the term key rather loosely. Wherever we write that 'a key - is used to sign data' it is assumed that the reader knows that it is - the private part of the key-pair that is used for signing. It is also - assumed that the reader will know that the public part of the - key-pair is published in the DNSKEY resource record and that it is - the public part of a key-pair that is used in key-exchanges. - -2. Time in DNSSEC - - Without DNSSEC all times in DNS are relative. The SOA's refresh, - retry and expiration timers are counters that are being used to - determine the time elapsed after a slave server synced (or tried to - sync) with a master server. The TTL value and the SOA minimum TTL - parameter [6] are used to to determine how long a forwarder should - cache data after it has been fetched from an authoritative server. - DNSSEC introduces the notion of an absolute time in the DNS. - Signatures in DNSSEC have an expiration date after which the - signature is invalid and the signed data is to be considered BAD. - -2.1 Time definitions - - In this document we will be using a number of time related terms. - Within the context of this document the following definitions apply: - - o "Signature validity period" - - - - - -Kolkman & Gieben Expires March 1, 2004 [Page 3] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - The period that a signature is valid. It starts at the time - specified in the signature inception field of the RRSIG RR and - ends at the time specified in the expiration field of the RRSIG - RR. - - o "Signature publication period" - - Time after which a signature made with a key is replaced with a - new signature made with the same key. This replacement takes - place by publishing the relevant RRSIG in the master zone file. - If a signature is published on time T0 and a new signature is - published on time T1, the signature publication period is T1 - - T0. If all signatures are refreshed at zone (re)signing then - the signature publication period is equal to the period between - two consecutive zone signing operations. - - o "Key publication period" - - The period for which the public part of the key is published in - the DNS. The public part of the key can be published in the DNS - while it has not yet been used to sign data. As soon as a - public key is published a brute force attack can be attempted - to recover the private key. Publishing the public key in - advance (and not signing any data with it) does not guard - against this attack. - - [Editor's Note: We don't use this term in the doc yet, is it - needed elsewhere and handy to define here? No:1 Yes:0] - - o "Maximum/Minimum Zone TTL" - - The maximum or minimum value of all the TTLs in a zone. - - -2.2 Time considerations - - Because of the expiration of signatures one should consider the - following. - - o The Maximum zone TTL of your zone data should be a fraction of - your signature validity period. - - If the TTL would be of similar order as the signature validity - period then all RRsets fetched during the validity period would - be cached until the signature expiration time. As a result - query behavior might become bursty. - - - - - -Kolkman & Gieben Expires March 1, 2004 [Page 4] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - We suggest the TTL on all the RRs in your zone to be at least - an order of magnitude smaller than your signature validity - period. - - o The signature publication period should at least be one maximum - TTL smaller than the signature validity period. - - If a zone is resigned shortly before the end of the signature - validity period this may cause simultaneous expiration of data - from caches which leads to bursty query behavior and increase - the load on authoritative servers. - - o The Minimum zone TTL should be long enough to fetch and verify all - the RRs in the authentication chain. - - 1. During validation, some data may expire before validation - is complete. The validator should be able to keep all the - data, until validation is complete. This applies to all data - in the chain of trust: DSs, DNSKEYs, RRSIGs, and the final - answers i.e. the RR that is returned for the initial query. - - 2. Frequent verification causes load on recursive - nameservers. Data at delegation points, DSs, DNSKEYs and - RRSIGs benefit from caching. The TTL on those should be - relatively long. - - We have seen events where data needed for verification of an - authentication chain had expired from caches. - - We suggest the TTL on DNSKEY and DSs to be at least of the - order 10 minutes to an hour and all the other RRs in your zone - to be at least 30 seconds. These are absolute minimum, we - recommend zone administrators to chose longer ones. - - [Editor's Note: this observation could be implementation - specific. We are not sure if we should leave this item] - - o Slave servers will need to be able to fetch newly signed zones - well before the data expires from your zone. - - If a properly implemented slave server is not able to contact a - master server for an extended period the data will at some - point expire and the slave server will not hand out any data. - If the server serves a DNSSEC zone than it may well happen that - the signatures expire well before the SOA expiration timer - counted down to zero. It is not possible to fully prevent this - from happening by tweaking the SOA parameters. But the effects - can be minimized if the SOA expiration time is of the same of - - - -Kolkman & Gieben Expires March 1, 2004 [Page 5] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - order of magnitude as or smaller than the signature validity - period. - - When a zone cannot be updated while signatures in that zone - have expired non-secure resolvers will continue to be able to - resolve the data served by the particular slave servers. Only - security aware resolvers that receive data with expired - signatures will experience problems. - - We suggest the SOA expiration timer being approximately one - third or one fourth of the signature validity period. - - We also suggest that operators of nameservers with slave zones - develop watchdogs to be able to spot these upcoming signature - expirations in slave zones, so that appropriate action can be - taken. - - o [Editor's Note: Need examples here] - - -3. Keys - -3.1 Motivations for the KSK and ZSK functions - - Delegation Signer [7] introduced the concept of key-signing and - zone-signing keys.The Key-signing-flag [4] introduced the concept of - a key with the Secure Entry Point flag set; a key that is the first - key from the zone when following an authentication chain. When using - a key-signing key with the SEP flag set (the parent has a DS RR - pointing to that DNSKEY) and when using zone-signing keys without the - SEP flag set (a practice which we recommend ) one can use the - following operational procedures. - - The zone-signing key can be used to sign all the data in a zone on a - regular basis. When a zone-signing key is to be rolled over no - interactions with the parent is needed. This allows for relatively - short "Signature Validity Periods" (order of days). - - The key-signing key (with the SEP flag set) is only to be used to - sign the Key RR set from the zone apex. If a key-signing key is to be - rolled over, there will be interactions with parties other than the - zone maintainer such as the registry of the parent zone or - administrators of verifying resolvers that have the particular key - configured as trusted entry points. Hence, the "Key Usage Time" of - these keys can and should be made much longer. Although, given a long - enough key, the "Key Usage Time" can be on the order of years we - suggest to plan for a "Key Usage Time" of the order of a few months - so that a key rollover remains an operational routine. - - - -Kolkman & Gieben Expires March 1, 2004 [Page 6] - -Internet-Draft DNSSEC Operational Practices September 2003 - - -3.2 Key security considerations - - In RFC2541 [2] a number of considerations with respect to the - security of keys are described. That document deals with the - generation, lifetime, size and storage of private keys. - - In Section 3 of RFC2541 [2], Eastlake does have some suggestions: 13 - months for long-lived keys and 36 days for transaction keys but - suggestions for key sizes are not made. - - If we read the long-lived key being a key that is used as key-signing - key and transaction keys being zone signing keys, then these - recommendations are good starting points for an operational - procedure. These recommendations will lead to rollovers occurring - frequently enough so that they can become part of 'operational - habits' and the procedure does not have to be reinvented every time a - key is replaced. - - When choosing a key sizes, zone administrators will need to take into - account how long a key will be used and how much data will be signed - during the key publication period. It is hard to give precise - recommendations but Lenstra and Verheul [9] supplied the following - table with lower bound estimates for cryptographic key sizes. Their - recommendations are based on a set of explicitly formulated parameter - settings, combined with existing data points about cryptosystems. For - details we refer to the original paper. - - Year RSA key sizes Elliptic Curve Key Size - 2000 952 132 - 2001 990 135 - 2002 1028 139 - 2003 1068 140 - 2004 1108 143 - - 2005 1149 147 - 2006 1191 148 - 2007 1235 152 - 2008 1279 155 - 2009 1323 157 - - - 2010 1369 160 - 2011 1416 163 - 2012 1464 165 - 2013 1513 168 - 2014 1562 172 - - 2015 1613 173 - - - -Kolkman & Gieben Expires March 1, 2004 [Page 7] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - 2016 1664 177 - 2017 1717 180 - 2018 1771 181 - 2019 1825 185 - - - 2020 1881 188 - 2021 1937 190 - 2022 1995 193 - 2023 2054 197 - 2024 2113 198 - - 2025 2174 202 - 2026 2236 205 - 2027 2299 207 - 2028 2362 210 - 2029 2427 213 - - Suppose you want your key to last 3 years and the current year is - 2003. Add 3 to 2003 equals 2006 and read of the sizes: 1191 for - asymmetric keys and 148 bits for elliptic curve keys. - - Note that adding only a "handful of bits" to the key size will - increase the key's resistance against brute force attacks. - -3.3 Key rollovers - - Key rollovers are a fact of life when using DNSSEC. A DNSSEC key - cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone - maintainers who are in the process of rolling their keys have to take - into account that data they have published in previous versions of - their zone still lives in caches. When deploying DNSSEC this becomes - an important consideration; ignoring data that may be in caches may - lead to loss of service for clients. - - The most pressing example of this is when zone material which is - signed with an old key is being validated by a resolver which does - not have the old zone key cached. If the old key is no longer present - in the current zone, this validation fails, marking the data BAD. - Alternatively, an attempt could be made to validate data which is - signed with a new key against an old key that lives in a local cache, - also resulting in data being marked BAD. - - To appreciate the situation one could think of a number of - authoritative servers that may not be instantaneously running the - same version of a zone and a security aware non-recursive resolver - that sits behind security aware caching forwarders. - - - - -Kolkman & Gieben Expires March 1, 2004 [Page 8] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - Note that KSK rollovers and ZSK rollovers are different. A zone-key - rollover can be handled in two different way: pre-publish and - [Editors note: ref please] double-sig. The pre-publish technique - works because the key-signing key stays the same during this ZSK - rollover. With this KSK a cache is able to validate the new keyset of - a zone. With a KSK rollover a cache can not validate the new keyset, - because it does not trust the new KSK. - - [Editors note: This needs more verbose explanation, nobody will - appreciate the situation just yet. Help with text and examples is - appreciated] - -3.3.1 Zone-signing key rollovers - - For zone-signing key rollovers there are two ways to make sure that - during the rollover the data still in caches can be verified with the - new keysets or the newly generated signatures can be verified with - the keys still in caches. One schema uses double signatures, it is - described in Section 3.3.1.1, the other uses key pre-publication - (Section 3.3.1.2). The pros, cons and recommendations are described - in Section 3.3.1.3. - -3.3.1.1 A double signature zone-signing key rollover - - This section shows how to perform a ZSK key rollover using the double - zone data signature scheme. - - During the rollover stage the new version of the zone file will need - to propagate to all authoritative servers and the data that exists in - (distant) caches will need to expire, this will take at least the - maximum Zone TTL . - - normal roll after - - SOA0 SOA1 SOA2 - RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) - RRSIG11(SOA1) - - DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 - RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) - RRSIG11(DNSKEY) - - - - - - - -Kolkman & Gieben Expires March 1, 2004 [Page 9] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - normal: Version 0 of the zone: DNSKEY 1 is a key-signing key. DNSKEY - 10 is used to sign all the data of the zone, it is the - zone-signing key. - - roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced - into the keyset and all the data in the zone is signed with DNSKEY - 10 and DNSKEY 11. The rollover period will need to exist until all - data from version 0 of the zone has expired from remote caches. - This will take at least the Maximum Zone TTL of the version 0 of - the zone. - - after: DNSKEY 10 is removed from the zone. All the signatures from - DNSKEY 10 are removed from the zone. The keyset, now only - containing DNSKEY 11 is resigned with the DNSKEY 1. - - At every instance the data from the previous version of the zone can - be verified with the key from the current version. And vice verse, - the data from the current version can be verified with the data from - the previous version of the zone. The duration of the rollover phase - and the period between rollovers should be at least the "Maximum Zone - TTL". - - To be on the safe side one could make sure that the rollover phase - lasts until the signature expiration time of the data in version 0 of - the zone. But this date could be considerable longer than the Maximum - Zone TTL, making the rollover a lengthly procedure. - - Note that in this example we assumed that the zone did not get - modified during the rollover. New data can be introduced in the zone - as long as it is signed with both keys. - -3.3.1.2 Pre-publish keyset rollover - - This section shows how to perform a ZSK rollover without the need to - sign all the data in a zone twice. We recommend this method because - it has advantages in the case of key compromises. If the old key gets - compromised the new key is already distributed in the DNS. The zone - administrator is then able to quickly switch to the new key and - remove the compromised key from the zone. Another major advantage is - that the zone size does not double, as is the case with the double - signature ZSK rollover. A small "HOWTO" for this kind of rollover can - be found in Appendix B. - - normal pre-roll roll after - - SOA0 SOA1 SOA2 SOA3 - RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) - - - - -Kolkman & Gieben Expires March 1, 2004 [Page 10] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 DNSKEY11 - RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) - - - normal: Version 0 of the zone: DNSKEY 1 is a key-signing key. DNSKEY - 10 is used to sign all the data of the zone, its the zone-signing - key. - - pre-roll: DNSKEY 11 is introduced in the keyset. Note that no - signatures are generated with this key yet, but this will not - prevent brute force attacks on the public key. The minimum - duration of this pre-roll phase is the time it takes for the data - to propagate to the authoritative servers plus TTL value on the - keyset. This would boil down to two times the Maximum Zone TTL. - - roll: - - At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign the - data in the zone (exclusively i.e. all the signatures from DNSKEY - 10 are removed from the zone.). DNSKEY 10 remains published in the - keyset. This way data that was loaded into caches from version 1 - of the zone can still be verified with key sets fetched from - version 2 of the zone. - - The minimum time that the keyset that includes DNSKEY 10 is to be - published is the time that it takes for zone data from the - previous version of the zone to expire from old caches i.e. the - time it takes for this zone to propagate to all authoritative - servers plus the Maximum Zone TTL value of any of the data in the - previous version of the zone. - - after: DNSKEY 10 is removed from the zone. The keyset, now only - containing DNSKEY 11 is resigned with the DNSKEY 1. - - The above scheme can be simplified a bit by always publishing the - "future" key immediately after the rollover. The scheme would look - like this (we show 2 rollovers); the future key is introduced in - "after" as DNSKEY 12 and again a newer one, numbered 13, in "2nd - after": - - - normal roll after 2nd roll 2nd after - - SOA0 SOA2 SOA3 SOA4 SOA5 - RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5) - - - -Kolkman & Gieben Expires March 1, 2004 [Page 11] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12 - DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13 - RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) - RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY) - - - Note that the key introduced after the rollover is not used for - production yet; the private key can thus be stored in a physically - secure manner and does not need to be 'fetched' every time a zone - needs to be signed. - - This scheme has the benefit that the key that is intended for future - use, can immediately be used during an emergency rollover under the - assumption that it was stored in a physically secure manner. - -3.3.1.3 Pros and cons of the schemes - - A double signature rollover: The drawback of this signing scheme is - that during the rollover the number of signatures in your zone - doubles, which may be prohibitive if you have very big zones. An - advantage is that it only requires three steps. - - Prepublish-keyset rollover: This rollover does not involve signing - the zone data twice. Instead, just before the actual rollover the - new key is published in the keyset and thus available for - cryptanalysis attacks. A small disavantage is that this process - requires four steps. Also the prepublish scheme is useless for - KSKs as explained in Section 3.3. - - -3.3.2 Key-signing key rollovers - - For the rollover of a key-signing key the same considerations as for - the rollover of a zone-signing key apply. However we can use a double - signature scheme to guarantee that old data (only the apex keyset) in - caches can be verified with a new keyset and vice versa. Since only - the keyset is signed with a KSK, size considerations do not apply. - - - normal roll after - - SOA0 SOA1 SOA2 - RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) - - DNSKEY1 DNSKEY1 DNSKEY2 - DNSKEY2 - DNSKEY10 DNSKEY10 DNSKEY10 - - - -Kolkman & Gieben Expires March 1, 2004 [Page 12] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) - RRSIG2 (DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) - - -4. Planning for emergency key rollover. - - This section deals with preparation for a possible key compromise. - Our advice is to have a documented procedure ready for when a key - compromise is suspected or confirmed. - - [Editors note: We are much in favor of a rollover tactic that keeps - the authentication chain intact as long as possible. This has as a - result that one has to take all the regular rollover properties into - account.] - - When the private material of one of your keys is compromised it can - be used by 'blackhats' for as long as a valid authentication chain - exists. A authentication chain remains intact for: - - as long as a signature over the compromised key in the - authentication chain is valid, - - as long as a parental DS RR (and signature) points to the - compromised key, - - as long as the key is anchored in a resolver and is used as a - starting point for validation. (This is the hardest to update.) - - While an authentication chain to your compromised key exists your - name-space is vulnerable to abuse by the "blackhat". Zone operators - have to make a trade off if the abuse of the compromised key is worse - than having data in caches that cannot be validated. If the zone - operator chooses to break the authentication chain to the compromised - key, data in caches signed with this key can not be validated. On the - other hand if the zone administrator chooses to take the path of a - regular roll-over the "blackhat" can spoof data so that it appears to - be valid, note that this kind of attack will usually be localized in - the Internet topology. - - -4.1 KSK compromise - - When the KSK has been compromised the parent must be notified as soon - as possible and through secure means. The keyset of the zone should - be resigned as soon as possible. Care must be taken to not break the - authentication chain. The local zone can only be resigned with the - new KSK after the parent's zone has been updated with the new KSK. - - - -Kolkman & Gieben Expires March 1, 2004 [Page 13] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - Before this update takes place it would be best to drop the security - status of a zone all together: the parent removes the DS of the child - at the next zone update. After that the child can be made secure - again. An additional danger of a key compromise is that the - compromised key can be used to facilitate a legitemate DNSKEY/DS and/ - or nameserver rollover at the parent. When that happens the domain - can be in dispute. An out of band and secure notify mechanism to - contact a parent is needed in this case. - -4.2 ZSK compromise - - Mainly because there is no parental interaction required when a ZSK - is compromised the situation is less severe than with with a KSK - compromise. The zone must still be resigned with a new ZSK as soon - as possible. As this is a local operation and requires no - communication between the parent and child this can be achieved - fairly quickly. One has to take into account though that just as with - a normal rollover the immediate disappearance from the old - compromised key may lead to verification problems. The - pre-publication scheme as discussed above minimizes that problem. - -4.3 Compromises of keys anchored in resolvers - - A key can also be pre-configured in resolvers. If DNSSEC is rolled - out as planned the root key should be pre-configured in every secure - aware resolver on the planet. [Editors Note: add more about - authentication of a newly received resolver key] - - If that key is compromised all the resolvers should be notified of - this fact. Zone administrators may consider setting up a mailing list - to communicate the fact that a SEP key is about to be rolled over. - This communication will of course need to be authenticated e.g. by - using digital signatures. - -5. Parental policies. - -5.1 Initial key exchanges and parental policies considerations. - - The initial key exchange is always subject to the policies set by the - parent (or its registry). When designing a key exchange policy one - should take into account that the authentication and authorization - mechanisms used during a key exchange should be as strong as the - authentication and authorization mechanisms used for the exchange of - delegation information between parent and child. - - Using the DNS itself as the source for the actual DNSKEY material - with an off-band check on the validity of the DNSKEY has the benefit - that it reduces the changes of operator error. A parental DNSKEY - - - -Kolkman & Gieben Expires March 1, 2004 [Page 14] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - download tool can make use of the SEP bit [4] to select the proper - key from a DNSSEC keyset; thereby reducing the change that the wrong - DNSKEY is sent. It can validate the self-signature over a key; - thereby verifying the ownership of the private key material. Besides, - by fetching the DNSKEY from the DNS one can be sure that the child - will not become invisible once the parent indicates the child is - secure by publishing the DS RR. - - Note: the off-band verification is still needed when the keymaterial - is fetched by a tool. The parent can not be sure if the DNSKEY RRs - where not spoofed. - -5.2 Storing keys so hashes can be regenerated - - When designing a registry system one should consider if the DNSKEYs - or the corresponding DSs are stored. Storing DNSKEYs will help during - troubleshooting while the overhead of calculating DS records from - them is minimal. - - Having a out-of-band mechanism, such as a WHOIS database, to find out - which keys are used to generate DS Resource Records for specific - owners may also help with troubleshooting. - -5.3 Security lameness checks. - - Security lameness is defined as the event that a parent has a DS - Resource Record that points to a non-existing DNSKEY RR. At key - exchange a parent should make sure that the childs key is actually - configured in the DNS before publishing a DS RR in its zone. Failure - to do so would render the child's zone marked "BAD". - - Child zones should be very careful removing DNSKEY material, - specifically SEP keys, for which a DS RR exist. - - Once a zone is "security lame" a fix (e.g. by removing a DS RR) will - take time to propagate through the DNS. - -5.4 SIG DS validity period. - - Since the DS can be replayed as long as it has a valid signature a - short signature validity period over the DS minimizes the time a - child is vulnerable in the case of a compromise of the child's KSK. - A signature validity period that is too short introduces the - possibility that a zone is marked BAD in case of a configuration - error in the signer; there may not be enough time to fix the problems - before signatures expire. Something as mundane as weekends show the - need for a DS signature lifetimes longer than 2 days. We recommend - the minimum for a DS signature validity period to be about a few - - - -Kolkman & Gieben Expires March 1, 2004 [Page 15] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - days. - - The maximum signature lifetime of the DS record depends on how long - child zones are willing to be vulnerable after a key compromise. We - consider a signature validity period of the order of one week a good - compromise between the operational constraints of the parent and - minimizing damage for the child. - -6. Security considerations - - DNSSEC adds data integrity to the DNS. This document tries to assess - considerations to operate a stable and secure DNSSEC service. - -7. Acknowledgments - - We, the folk mentioned as authors, only acted as editors. Most of the - ideas in this draft where the result of collective efforts during - workshops and discussions and try outs. - - At the risk of forgetting individuals who where the original - contributors of the ideas we like to acknowledge people who where - actively involved in the compilation of this document. In - alphabetical order: Olafur Gudmundsson, Wesley Griffin, Michael - Richardson, Scott Rose, Rick van Rein, Tim McGinnis. - - Kolkman and Gieben take the blame for all mistakes. - -Normative References - - [1] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [2] Eastlake, D., "DNS Security Operational Considerations", RFC - 2541, March 1999. - - [3] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key - (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work - in progress), February 2003. - -Informative References - - [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC - - - -Kolkman & Gieben Expires March 1, 2004 [Page 16] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - 2308, March 1998. - - [7] Gudmundsson, O., "Delegation Signer Resource Record", - draft-ietf-dnsext-delegation-signer-13 (work in progress), March - 2003. - - [8] Arends, R., "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in - progress), March 2003. - - [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", - The Journal of Cryptology 14 (255-293), 2001. - - -Authors' Addresses - - Olaf M. Kolkman - RIPE NCC - Singel 256 - Amsterdam 1016 AB - NL - - Phone: +31 20 535 4444 - EMail: olaf@ripe.net - URI: http://www.ripe.net/ - - - Miek Gieben - NLnet Labs - Kruislaan 419 - Amsterdam 1098 VA - NL - - EMail: miek@nlnetlabs.nl - URI: http://www.nlnetlabs.nl - -Appendix A. Terminology - - In this document there is some jargon used that is defined in other - documents. In most cases we have not copied the text from the - documents defining the terms but give a more elaborate explanation of - the meaning. Note that these explanations should not be seen as - authoritative. - - Private and Public Keys: DNSSEC secures the DNS through the use of - public key cryptography. Public key cryptography is based on the - existence of 2 keys, a public key and a private key. The public - keys are published in the DNS by use of the DNSKEY Resource Record - - - -Kolkman & Gieben Expires March 1, 2004 [Page 17] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - (DNSKEY RR). Private keys are supposed to remain private i.e. - should not be exposed to parties not-authorized to do the actual - signing. - - Signer: The system that has access to the private key material and - signs the Resource Record sets in a zone. A signer may be - configured to sign only parts of the zone e.g. only those RRsets - for which existing signatures are about to expire. - - KSK: A Key-Signing key (KSK) is a key that is used for exclusively - signing the apex keyset. The fact that a key is a KSK is only - relevant to the signing tool. - - ZSK: A Zone signing key (ZSK) is a key that is used for signing all - data in a zone. The fact that a key is a ZSK is only relevant to - the signing tool. - - BAD: [Editors Note: a reference here] A RRset in DNSSEC is marked - "bad" when a signature of a RRset does not validate against the - DNSKEY. Even is the key itself was not marked BAD. BAD data is not - cached. - - Singing the Zone File: The term used for the event where an - administrator joyfully signs its zone file while producing melodic - sound patterns. - - -Appendix B. Zone-signing key rollover howto - - Using the pre-published signature scheme and the most conservative - method to assure oneself that data does not live in distant caches - here follows the "HOWTO". [WES: has some comments about this] - - STEP 0, the preparation: Create two keys and publish them both in - your keyset. Mark one of the keys as "active" and the other as - "published". Use the "active" key for signing your zone data. - Store the private part of the "published" key, preferably - off-line. - - STEP 1, determine expiration: At the beginning of the rollover: - make a note of the highest expiration time of signatures in your - zonefile created with the current key currently marked as - "active". - - Wait until the expiration time marked in STEP 1 - - - - - - -Kolkman & Gieben Expires March 1, 2004 [Page 18] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - STEP 2 Then start using the key that was marked as "published" to - sign your data i.e. mark it as "active". Stop using the key that - was marked as "active", mark it as "rolled". - - STEP 3: It is safe to engage in a new rollover (STEP 1) after at - least one "signature validity period". - - -Appendix C. Typographic conventions - - The following typographic conventions are used in this document: - - Key notation: A key is denoted by KEYx, where x is a number, x could - be thought of as the key id. - - RRset notations: RRs are only denoted by the type all other - information, owner, class, rdata and TTL is left out. Thus: - example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a - list of RRs. A example of this would be: A1,A2, specifying the - RRset containing two A records. This could again be abreviated to - just: A. - - Signature notation: Signatures are denoted as SIGx(RRset), which - means that RRset is signed with KEYx. - - Zone representation: Using the above notation we have simplify the - representation of a signed zone by leaving out all unneeded - details such as the names and by just representing all data by - "SOAx" - - SOA representation: Soa's are represented as SOA x, where x is the - serial number. - - Using this notation the following zone : - - - example.net. 600 IN SOA ns.example.net. ernie.example.net. ( - 10 ; serial - 450 ; refresh (7 minutes 30 seconds) - 600 ; retry (10 minutes) - 345600 ; expire (4 days) - 300 ; minimum (5 minutes) - ) - 600 RRSIG SOA 5 2 600 20130522213204 ( - 20130422213204 14 example.net. - cmL62SI6iAX46xGNQAdQ... ) - 600 NS a.iana-servers.net. - 600 NS b.iana-servers.net. - - - -Kolkman & Gieben Expires March 1, 2004 [Page 19] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - 600 RRSIG NS 5 2 600 20130507213204 ( - 20130407213204 14 example.net. - SO5epiJei19AjXoUpFnQ ... ) - 3600 DNSKEY 256 3 5 ( - EtRB9MP5/AvOuVO0I8XDxy0... - ) ; key id = 14 - 3600 DNSKEY 256 3 5 ( - gsPW/Yy19GzYIY+Gnr8HABU... - ) ; key id = 15 - 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( - 20130422213204 14 example.net. - J4zCe8QX4tXVGjV4e1r9... ) - 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( - 20130422213204 15 example.net. - keVDCOpsSeDReyV6O... ) - 600 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC - 600 RRSIG NSEC 5 2 600 20130507213204 ( - 20130407213204 14 example.net. - obj3HEp1GjnmhRjX... ) - a.example.net. 600 IN TXT "A label" - 600 RRSIG TXT 5 3 600 20130507213204 ( - 20130407213204 14 example.net. - IkDMlRdYLmXH7QJnuF3v... ) - 600 NSEC b.example.com. TXT RRSIG NSEC - 600 RRSIG NSEC 5 3 600 20130507213204 ( - 20130407213204 14 example.net. - bZMjoZ3bHjnEz0nIsPMM... ) - - ... - - - is reduced to the following represenation: - - SOA10 - RRSIG14(SOA10) - - DNSKEY14 - DNSKEY15 - - RRSIG14(KEY) - RRSIG15(KEY) - - The rest of the zone data has the same signature as the SOA record, - i.e a RRSIG created with DNSKEY 14. - -Appendix D. Document Details and Changes - - This section is to be removed by the RFC editor if and when the - - - -Kolkman & Gieben Expires March 1, 2004 [Page 20] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - document is published. - - $Header: /var/cvs/dnssec-key/ - draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.5 2003/10/10 - 09:49:07 dnssec Exp $ - -D.1 draft-ietf-dnsop-dnssec-operational-practices-00 - - Submission as working group document. This document is a modified and - updated version of draft-kolkman-dnssec-operational-practices-00. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires March 1, 2004 [Page 21] - -Internet-Draft DNSSEC Operational Practices September 2003 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Kolkman & Gieben Expires March 1, 2004 [Page 22] - -Internet-Draft DNSSEC Operational Practices September 2003 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires March 1, 2004 [Page 23] - diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt new file mode 100644 index 00000000..04815175 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt @@ -0,0 +1,1344 @@ +
+DNSOP O. Kolkman
+Internet-Draft RIPE NCC
+Expires: August 30, 2004 R. Gieben
+ NLnet Labs
+ March 2004
+
+
+ DNSSEC Operational Practices
+ draft-ietf-dnsop-dnssec-operational-practices-01.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on August 30, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document describes a set of practices for operating a DNSSEC
+ aware environment. The target audience is zone administrators
+ deploying DNSSEC that need a guide to help them chose appropriate
+ values for DNSSEC parameters. It also discusses operational matters
+ such as key rollovers, KSK and ZSK considerations and related
+ matters.
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 1]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3
+ 1.2 Keeping the Chain of Trust Intact . . . . . . . . . . . . 3
+ 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2 Time Considerations . . . . . . . . . . . . . . . . . . . 5
+ 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1 Motivations for the KSK and ZSK Functions . . . . . . . . 7
+ 3.2 Key Security Considerations . . . . . . . . . . . . . . . 8
+ 3.2.1 Key Validity Period . . . . . . . . . . . . . . . . . 8
+ 3.2.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . 8
+ 3.2.3 Key Sizes . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.3.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10
+ 3.3.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 13
+ 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 14
+ 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16
+ 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.1 Initial Key Exchanges and Parental Policies
+ Considerations . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 16
+ 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 17
+ 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 17
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
+ 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
+ A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 20
+ C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 20
+ D. Document Details and Changes . . . . . . . . . . . . . . . . . 22
+ D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22
+ D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22
+ Intellectual Property and Copyright Statements . . . . . . . . 23
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 2]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+1. Introduction
+
+ During workshops and early operational deployment tests, operators
+ and system administrators gained experience about operating DNSSEC
+ aware DNS services. This document translates these experiences into
+ a set of practices for zone administrators. At the time of writing,
+ there exists very little experience with DNSSEC in production
+ environments, this document should therefore explicitly not be seen
+ as represented 'Best Current Practices'.
+
+ The procedures herein are focused on the maintenance of signed zones
+ (i.e. signing and publishing zones on authoritative servers). It is
+ intended that maintenance of zones such as resigning or key rollovers
+ be transparent to any verifying clients on the Internet.
+
+ The structure of this document is as follows: It begins with
+ discussing some of the considerations with respect to timing
+ parameters of DNS in relation to DNSSEC (Section 2). Aspects of key
+ management such as key rollover schemes are described in Section 3.
+ Emergency rollover considerations are addressed in Section 4. The
+ typographic conventions used in this document are explained in
+ Appendix C.
+
+ Since this is a document with operational suggestions and there are
+ no protocol specifications, the RFC2119 [5] language does not apply.
+
+1.1 The Use of the Term 'key'
+
+ It is assumed that the reader is familiar with the concept of
+ asymmetric keys on which DNSSEC is based (Public Key Cryptography
+ [Ref to Schneider?]). Therefore, this document will use the term
+ 'key' rather loosely. Where it is written that 'a key is used to sign
+ data' it is assumed that the reader understands that it is the
+ private part of the key-pair that is used for signing. It is also
+ assumed that the reader understands that the public part of the
+ key-pair is published in the DNSKEY resource record and that it is
+ used in key-exchanges.
+
+1.2 Keeping the Chain of Trust Intact
+
+ Maintaining a valid chain of trust is important because broken chains
+ of trust will result in data being marked as bogus, which may cause
+ entire (sub)domains to become invisible to verifying clients. The
+ administrators of secured zones have to realise that their zone is,
+ to their clients, part of a chain of trust.
+
+ As mentioned in the introduction, the procedures herein are intended
+ to ensure maintenance of zones, such as resigning or key rollovers,
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 3]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ be transparent to the verifying clients on the Internet.
+ Administrators of secured zones will have to keep in mind that data
+ published on an authoritative primary server will not be immediately
+ seen by verifying clients; it may take some time for the data to be
+ transfered to other secondary authoritative nameservers, during which
+ period clients may be fetching data from caching non-authoritative
+ servers. For the verifying clients it is important that data from
+ secured zones can be used to build chains of trust regardless of
+ whether the data came directly from an authoritative server, a
+ caching nameserver or some middle box. Only by carefully using the
+ available timing parameters can a zone administrator assure that the
+ data necessary for verification can be obtained.
+
+ The responsibility for maintaining the chain of trust is shared by
+ administrators of secured zones in the chain of trust. This is most
+ obvious in the case of a 'key compromise' when a trade off between
+ maintaining a valid chain of trust and the fact that the key has been
+ stolen, must be made.
+
+ The zone administrator will have to make a tradeoff between keeping
+ the chain of trust intact -thereby allowing for attacks with the
+ compromised key- or to deliberately break the chain of trust thereby
+ making secured subdomains invisible to security aware resolvers. Also
+ see Section 4.
+
+2. Time in DNSSEC
+
+ Without DNSSEC all times in DNS are relative. The SOA's refresh,
+ retry and expiration timers are counters that are used to determine
+ the time elapsed after a slave server syncronised (or tried to
+ syncronise) with a master server. The Time to Live (TTL) value and
+ the SOA minimum TTL parameter [6] are used to determine how long a
+ forwarder should cache data after it has been fetched from an
+ authoritative server. DNSSEC introduces the notion of an absolute
+ time in the DNS. Signatures in DNSSEC have an expiration date after
+ which the signature is marked as invalid and the signed data is to be
+ considered bogus.
+
+2.1 Time Definitions
+
+ In this document we will be using a number of time related terms.
+ Within the context of this document the following definitions apply:
+ o "Signature validity period"
+ The period that a signature is valid. It starts at the time
+ specified in the signature inception field of the RRSIG RR and
+ ends at the time specified in the expiration field of the RRSIG
+ RR.
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 4]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ o "Signature publication period"
+ Time after which a signature (made with a specific key) is
+ replaced with a new signature (made with the same key). This
+ replacement takes place by publishing the relevant RRSIG in the
+ master zone file. If a signature is published at time T0 and a
+ new signature is published at time T1, the signature
+ publication period is T1 - T0.
+ If all signatures are refreshed at zone (re)signing then the
+ signature publication period is equal signature validity
+ period.
+ o "Maximum/Minimum Zone TTL"
+ The maximum or minimum value of all the TTLs in a zone.
+
+2.2 Time Considerations
+
+ Because of the expiration of signatures, one should consider the
+ following.
+ o The Maximum Zone TTL of your zone data should be a fraction of
+ your signature validity period.
+ If the TTL would be of similar order as the signature validity
+ period, then all RRsets fetched during the validity period
+ would be cached until the signature expiration time. As a
+ result query load on authoritative servers would peak at
+ signature expiration time.
+ To avoid query load peaks we suggest the TTL on all the RRs in
+ your zone to be at least a few times smaller than your
+ signature validity period.
+ o The signature publication period should be at least one maximum
+ TTL smaller than the signature validity period.
+ Resigning a zone shortly before the end of the signature
+ validity period may cause simultaneous expiration of data from
+ caches. This in turn may lead to peaks in the load on
+ authoritative servers.
+ o The Minimum zone TTL should be long enough to both fetch and
+ verify all the RRs in the authentication chain.
+ 1. During validation, some data may expire before the
+ validation is complete. The validator should be able to keep
+ all data, until is completed. This applies to all RRs needed
+ to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and
+ the final answers i.e. the RR that is returned for the
+ initial query.
+ 2. Frequent verification causes load on recursive
+ nameservers. Data at delegation points, DSs, DNSKEYs and
+ RRSIGs benefit from caching. The TTL on those should be
+ relatively long.
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 5]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ We have seen events where data needed for verification of an
+ authentication chain had expired from caches.
+ We suggest the TTL on DNSKEY and DSs to be between ten minutes
+ and one hour. We recommend zone administrators to chose TTLs
+ longer than half a minute.
+ [Editor's Note: this observation could be implementation
+ specific. We are not sure if we should leave this item]
+ o Slave servers will need to be able to fetch newly signed zones
+ well before the data expires from your zone.
+ 'Better no answers than bad answers.'
+ If a properly implemented slave server is not able to contact a
+ master server for an extended period the data will at some
+ point expire and the slave server will not hand out any data.
+ If the server serves a DNSSEC zone than it may well happen that
+ the signatures expire well before the SOA expiration timer
+ counts down to zero. It is not possible to completely prevent
+ this from happening by tweaking the SOA parameters. However,
+ the effects can be minimized where the SOA expiration time is
+ equal or smaller than the signature validity period.
+ The consequence of an authoritative server not being able to
+ update a zone, whilst that zone includes expired signaturs, is
+ that non-secure resolvers will continue to be able to resolve
+ data served by the particular slave servers. Security aware
+ resolvers will experience problems.
+ We suggest the SOA expiration timer being approximately one
+ third or one fourth of the signature validity period. It will
+ allow problems with transfers from the master server to be
+ noticed before the actual signature time out.
+ We suggest that operators of nameservers with slave zones
+ develop 'watch dogs' to spot upcoming signature expirations in
+ slave zones, and take appropriate action.
+ When determining the value for the expiration parameter one has
+ to take the following into account: What are the chances that
+ all my secondary zones expire; How quickly can I reach an
+ administrator and load a valid zone? All these arguments are
+ not DNSSEC specific.
+
+3. Keys
+
+ In the DNSSEC protocol there is only one type of key, the zone key.
+ With this key, the data in a zone is signed.
+
+ To make zone re-signing and key rollovers procedures easier to
+ implement, it is possible to use one or more keys as Key Signing Keys
+ (KSK) these keys will only sign the apex DNSKEY RRs in a zone. Other
+ keys can be used to sign all the RRsets in a zone and are referred to
+ as Zone Signing Keys (ZSK). In this document we assume that KSKs are
+ the subset of keys that are used for key exchanges with the parents
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 6]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ and potentially for configuration as trusted anchors - the so called
+ Secure Entry Point keys (SEP). In this document we assume a
+ one-to-one mapping between KSK and SEP keys and we assume the SEP
+ flag [4] to be set on KSKs.
+
+3.1 Motivations for the KSK and ZSK Functions
+
+ Differentiating between the KSK to ZSK functions has several
+ advantages:
+
+ o Making the KSK stronger (i.e. using more bits in the key material)
+ has little operational impact since it is only used to sign a
+ small fraction of the zone data.
+ o As the KSK is only used to sign a keyset, which is most probably
+ updated less frequently than other data in the zone, it can be
+ stored separately from (and thus in a safer location than) the
+ ZSK.
+ o A KSK can be used for longer periods.
+ o No parent/child interaction is required when ZSKs are updated.
+
+ The KSK is used less than ZSK, once a keyset is signed with the KSK
+ all the keys in the keyset can be used as ZSK. If a ZSK is
+ compromised, it can be simply dropped from the keyset. The new keyset
+ is then resigned with the KSK.
+
+ Given the assumption that for KSKs the SEP flag is set, the KSK can
+ be distinguished from a ZSK by examining the flag field in the DNSKEY
+ RR. If the flag field is an odd number it is a KSK if it is an even
+ number it is a ZSK e.g. a value of 256 and a key signing key has 257.
+
+ The zone-signing key can be used to sign all the data in a zone on a
+ regular basis. When a zone-signing key is to be rolled, no
+ interaction with the parent is needed. This allows for relatively
+ short "Signature Validity Periods". That is, Signature Validity
+ Periods of the order of days.
+
+ The key-signing key is only to be used to sign the Key RR set from
+ the zone apex. If a key-signing key is to be rolled over, there will
+ be interactions with parties other than the zone administrator such
+ as the registry of the parent zone or administrators of verifying
+ resolvers that have the particular key configured as trusted entry
+ points. Hence, the "Key Usage Time" of these keys can and should be
+ made much longer. Although, given a long enough key, the "Key Usage
+ Time" can be on the order of years we suggest to plan for a "Key
+ Usage Time" of the order of a few months so that a key rollover
+ remains an operational routine.
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 7]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+3.2 Key Security Considerations
+
+ Keys in DNSSEC have a number of parameters which should all be chosen
+ with care, the most important once are: size, algorithm and the key
+ validity period (its lifetime).
+
+3.2.1 Key Validity Period
+
+ RFC2541 [2] describes a number of considerations with respect to the
+ security of keys. The document deals with the generation, lifetime,
+ size and storage of private keys.
+
+ In Section 3 of RFC2541 [2] there are some suggestions for a key
+ validity period: 13 months for long-lived keys and 36 days for
+ transaction keys but suggestions for key sizes are not made.
+
+ If we say long-lived keys are key-signing keys and transactions keys
+ are zone-signing keys, these recommendations will lead to rollovers
+ occurring frequently enough to become part of 'operational habits';
+ the procedure does not have to be reinvented every time a key is
+ replaced.
+
+3.2.2 Key Algorithm
+
+ We recommend you choose RSA/SHA-1 as the preferred algorithm for the
+ key. RSA has been developed in an open and transparent manner. As the
+ patent on RSA expired in 2001, its use is now also free. The current
+ known attacks on RSA can be defeated by making your key longer. As
+ the MD5 hashing algorithm is showing (theoretical) cracks, we
+ recommend the usage of SHA1.
+
+3.2.3 Key Sizes
+
+ When choosing key sizes, zone administrators will need to take into
+ account how long a key will be used and how much data will be signed
+ during the key publication period. It is hard to give precise
+ recommendations but Lenstra and Verheul [9] supplied the following
+ table with lower bound estimates for cryptographic key sizes. Their
+ recommendations are based on a set of explicitly formulated parameter
+ settings, combined with existing data points about cryptosystems. For
+ details we refer to the original paper.
+
+ [Editor's Note: DSA???]
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 8]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ Year RSA Key Sizes Elliptic Curve Key Size
+ 2000 952 132
+ 2001 990 135
+ 2002 1028 139
+ 2003 1068 140
+ 2004 1108 143
+
+ 2005 1149 147
+ 2006 1191 148
+ 2007 1235 152
+ 2008 1279 155
+ 2009 1323 157
+
+
+ 2010 1369 160
+ 2011 1416 163
+ 2012 1464 165
+ 2013 1513 168
+ 2014 1562 172
+
+ 2015 1613 173
+ 2016 1664 177
+ 2017 1717 180
+ 2018 1771 181
+ 2019 1825 185
+
+
+ 2020 1881 188
+ 2021 1937 190
+ 2022 1995 193
+ 2023 2054 197
+ 2024 2113 198
+
+ 2025 2174 202
+ 2026 2236 205
+ 2027 2299 207
+ 2028 2362 210
+ 2029 2427 213
+
+ For example, should you wish your key to last three years from 2003,
+ check the RSA keysize values for 2006 in this table. In this case
+ 1191.
+
+3.3 Key Rollovers
+
+ Key rollovers are a fact of life when using DNSSEC. A DNSSEC key
+ cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone
+ administrators who are in the process of rolling their keys have to
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 9]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ take into account that data published in previous versions of their
+ zone still lives in caches. When deploying DNSSEC, this becomes an
+ important consideration; ignoring data that may be in caches may lead
+ to loss of service for clients.
+
+ The most pressing example of this is when zone material signed with
+ an old key is being validated by a resolver which does not have the
+ old zone key cached. If the old key is no longer present in the
+ current zone, this validation fails, marking the data bogus.
+ Alternatively, an attempt could be made to validate data which is
+ signed with a new key against an old key that lives in a local cache,
+ also resulting in data being marked bogus.
+
+ To appreciate the situation one could think of a number of
+ authoritative servers that may not be instantaneously running the
+ same version of a zone and a security aware non-recursive resolver
+ that sits behind security aware caching forwarders.
+
+ Note that KSK rollovers and ZSK rollovers are different. A zone-key
+ rollover can be handled in two different ways: pre-publish (Section
+ Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The
+ pre-publish technique works because the key-signing key stays the
+ same during this ZSK rollover. With this KSK a cache is able to
+ validate the new keyset of a zone. With a KSK rollover a cache can
+ not validate the new keyset, because it does not trust the new KSK.
+
+ [Editors note: This needs more verbose explanation, nobody will
+ appreciate the situation just yet. Help with text and examples is
+ appreciated]
+
+3.3.1 Zone-signing Key Rollovers
+
+ For zone-signing key rollovers there are two ways to make sure that
+ during the rollover data still cached can be verified with the new
+ keysets or newly generated signatures can be verified with the keys
+ still in caches. One schema uses double signatures, it is described
+ in Section 3.3.1.2, the other uses key pre-publication (Section
+ 3.3.1.1). The pros, cons and recommendations are described in Section
+ 3.3.1.3.
+
+3.3.1.1 Pre-publish Keyset Rollover
+
+ This section shows how to perform a ZSK rollover without the need to
+ sign all the data in a zone twice - the so called "prepublish
+ rollover". We recommend this method because it has advantages in the
+ case of key compromise. If the old key is compromised, the new key
+ has already been distributed in the DNS. The zone administrator is
+ then able to quickly switch to the new key and remove the compromised
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 10]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ key from the zone. Another major advantage is that the zone size does
+ not double, as is the case with the double signature ZSK rollover. A
+ small "HOWTO" for this kind of rollover can be found in Appendix B.
+
+ normal pre-roll roll after
+
+ SOA0 SOA1 SOA2 SOA3
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
+
+ DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
+ DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
+ DNSKEY11 DNSKEY11
+ RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
+
+
+ normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
+ DNSKEY 10 is used to sign all the data of the zone, the
+ zone-signing key.
+ pre-roll: DNSKEY 11 is introduced into the keyset. Note that no
+ signatures are generated with this key yet, but this does not
+ secure against brute force attacks on the public key. The minimum
+ duration of this pre-roll phase is the time it takes for the data
+ to propagate to the authoritative servers plus TTL value of the
+ keyset. This equates to two times the Maximum Zone TTL.
+ roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign
+ the data in the zone exclusively (i.e. all the signatures from
+ DNSKEY 10 are removed from the zone). DNSKEY 10 remains published
+ in the keyset. This way data that was loaded into caches from
+ version 1 of the zone can still be verified with key sets fetched
+ from version 2 of the zone.
+ The minimum time that the keyset including DNSKEY 10 is to be
+ published is the time that it takes for zone data from the
+ previous version of the zone to expire from old caches i.e. the
+ time it takes for this zone to propagate to all authoritative
+ servers plus the Maximum Zone TTL value of any of the data in the
+ previous version of the zone.
+ after: DNSKEY 10 is removed from the zone. The keyset, now only
+ containing DNSKEY 11 is resigned with the DNSKEY 1.
+
+ The above scheme can be simplified by always publishing the "future"
+ key immediately after the rollover. The scheme would look as follows
+ (we show two rollovers); the future key is introduced in "after" as
+ DNSKEY 12 and again a newer one, numbered 13, in "2nd after":
+
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 11]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ normal roll after 2nd roll 2nd after
+
+ SOA0 SOA2 SOA3 SOA4 SOA5
+ RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5)
+
+ DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
+ DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12
+ DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13
+ RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
+ RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY)
+
+
+ Note that the key introduced after the rollover is not used for
+ production yet; the private key can thus be stored in a physically
+ secure manner and does not need to be 'fetched' every time a zone
+ needs to be signed.
+
+ This scheme has the benefit that the key that is intended for future
+ use: immediately during an emergency rollover assuming that the
+ private key was stored in a physically secure manner.
+
+3.3.1.2 Double Signature Zone-signing Key Rollover
+
+ This section shows how to perform a ZSK key rollover using the double
+ zone data signature scheme, aptly named "double sig rollover".
+
+ During the rollover stage the new version of the zone file will need
+ to propagate to all authoritative servers and the data that exists in
+ (distant) caches will need to expire, this will take at least the
+ maximum Zone TTL .
+
+ normal roll after
+
+ SOA0 SOA1 SOA2
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
+ RRSIG11(SOA1)
+
+ DNSKEY1 DNSKEY1 DNSKEY1
+ DNSKEY10 DNSKEY10 DNSKEY11
+ DNSKEY11
+ RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
+ RRSIG11(DNSKEY)
+
+ normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
+ DNSKEY 10 is used to sign all the data of the zone, the
+ zone-signing key.
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 12]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
+ into the keyset and all the data in the zone is signed with DNSKEY
+ 10 and DNSKEY 11. The rollover period will need to exist until all
+ data from version 0 of the zone has expired from remote caches.
+ This will take at least the maximum Zone TTL of version 0 of the
+ zone.
+ after: DNSKEY 10 is removed from the zone. All the signatures from
+ DNSKEY 10 are removed from the zone. The keyset, now only
+ containing DNSKEY 11, is resigned with DNSKEY 1.
+
+ At every instance the data from the previous version of the zone can
+ be verified with the key from the current version and vice verse. The
+ data from the current version can be verified with the data from the
+ previous version of the zone. The duration of the rollover phase and
+ the period between rollovers should be at least the "Maximum Zone
+ TTL".
+
+ Making sure that the rollover phase lasts until the signature
+ expiration time of the data in version 0 of the zone is recommended.
+ However, this date could be considerably longer than the Maximum Zone
+ TTL, making the rollover a lengthy procedure.
+
+ Note that in this example we assumed that the zone was not modified
+ during the rollover. New data can be introduced in the zone as long
+ as it is signed with both keys.
+
+3.3.1.3 Pros and Cons of the Schemes
+
+ Prepublish-keyset rollover: This rollover does not involve signing
+ the zone data twice. Instead, just before the actual rollover, the
+ new key is published in the keyset and thus available for
+ cryptanalysis attacks. A small disavantage is that this process
+ requires four steps. Also the prepublish scheme will not work for
+ KSKs as explained in Section 3.3.
+ Double signature rollover: The drawback of this signing scheme is
+ that during the rollover the number of signatures in your zone
+ doubles, this may be prohibitive if you have very big zones. An
+ advantage is that it only requires three steps.
+
+3.3.2 Key-signing Key Rollovers
+
+ For the rollover of a key-signing key the same considerations as for
+ the rollover of a zone-signing key apply. However we can use a double
+ signature scheme to guarantee that old data (only the apex keyset) in
+ caches can be verified with a new keyset and vice versa.
+
+ Since only the keyset is signed with a KSK, zone size considerations
+ do not apply.
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 13]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ normal roll after
+
+ SOA0 SOA1 SOA2
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2)
+
+ DNSKEY1 DNSKEY1 DNSKEY2
+ DNSKEY2
+ DNSKEY10 DNSKEY10 DNSKEY10
+ RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)
+ RRSIG2 (DNSKEY)
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)
+
+ normal: Version 0 of the zone. The parental DS points to DNSKEY1.
+ Before the rollover starts the child will have to verify what the
+ TTL is of the DS RR that points to DNSKEY1 - it is needed during
+ the rollover and we refer to the value as TTL_DS.
+ roll: During the rollover phase the zone administrator generates a
+ second KSK, DNSKEY2. The key is provided to the parent and the
+ child will have to wait until a new DS RR has been generated that
+ points to DNSKEY2. After that DS RR has been published on _all_
+ servers authoritative for the parents zone, the zone administrator
+ has to wait at least TTL_DS to make sure that the old DS RR has
+ expired from distant caches.
+ after: DNSKEY1 has been removed.
+
+ The scenario above puts the responsibility for maintaining a valid
+ chain of trust with the child. It also is based on the premises that
+ the parent only has one DS RR (per algorithm) per zone. St John [The
+ draft has expired] proposed a mechanism where using an established
+ trust relation, the interaction can be performed in-band. In this
+ mechanism there are periods where there are two DS RRs at the parent.
+
+ [Editors note: We probably need to mention more]
+
+4. Planning for Emergency Key Rollover
+
+ This section deals with preparation for a possible key compromise.
+ Our advice is to have a documented procedure ready for when a key
+ compromise is suspected or confirmed.
+
+ [Editors note: We are much in favor of a rollover tactic that keeps
+ the authentication chain intact as long as possible. This means that
+ one has to take all the regular rollover properties into account.]
+
+ When the private material of one of your keys is compromised it can
+ be used for as long as a valid authentication chain exists. An
+ authentication chain remains intact for:
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 14]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ o as long as a signature over the compromised key in the
+ authentication chain is valid,
+ o as long as a parental DS RR (and signature) points to the
+ compromised key,
+ o as long as the key is anchored in a resolver and is used as a
+ starting point for validation. (This is the hardest to update.)
+ While an authentication chain to your compromised key exists, your
+ name-space is vulnerable to abuse by the malicious key holder (i.e.
+ the owner of the compromised key). Zone operators have to make a
+ trade off if the abuse of the compromised key is worse than having
+ data in caches that cannot be validated. If the zone operator chooses
+ to break the authentication chain to the compromised key, data in
+ caches signed with this key cannot be validated. However, if the zone
+ administrator chooses to take the path of a regular roll-over, the
+ malicious key holder can spoof data so that it appears to be valid,
+ note that this kind of attack will usually be localised in the
+ Internet topology.
+
+
+4.1 KSK Compromise
+
+ When the KSK has been compromised the parent must be notified as soon
+ as possible using secure means. The keyset of the zone should be
+ resigned as soon as possible. Care must be taken to not break the
+ authentication chain. The local zone can only be resigned with the
+ new KSK after the parent's zone has been updated with the new KSK.
+ Before this update takes place it would be best to drop the security
+ status of a zone all together: the parent removes the DS of the child
+ at the next zone update. After that the child can be made secure
+ again.
+
+ An additional danger of a key compromise is that the compromised key
+ can be used to facilitate a legitimate DNSKEY/DS and/or nameserver
+ rollover at the parent. When that happens the domain can be in
+ dispute. An out of band and secure notify mechanism to contact a
+ parent is needed in this case.
+
+4.2 ZSK Compromise
+
+ Primarily because there is no parental interaction required when a
+ ZSK is compromised, the situation is less severe than with with a KSK
+ compromise. The zone must still be resigned with a new ZSK as soon
+ as possible. As this is a local operation and requires no
+ communication between the parent and child this can be achieved
+ fairly quickly. However, one has to take into account that just as
+ with a normal rollover the immediate disappearance from the old
+ compromised key may lead to verification problems. The
+ pre-publication scheme as discussed above minimises such problems.
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 15]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+4.3 Compromises of Keys Anchored in Resolvers
+
+ A key can also be pre-configured in resolvers. If DNSSEC is rolled
+ out as planned the root key should be pre-configured in every secure
+ aware resolver on the planet. [Editors Note: add more about
+ authentication of a newly received resolver key]
+
+ If trust-anchor keys are compromised, the resolvers using these keys
+ should be notified of this fact. Zone administrators may consider
+ setting up a mailing list to communicate the fact that a SEP key is
+ about to be rolled over. This communication will of course need to be
+ authenticated e.g. by using digital signatures.
+
+5. Parental Policies
+
+5.1 Initial Key Exchanges and Parental Policies Considerations
+
+ The initial key exchange is always subject to the policies set by the
+ parent (or its registry). When designing a key exchange policy one
+ should take into account that the authentication and authorisation
+ mechanisms used during a key exchange should be as strong as the
+ authentication and authorisation mechanisms used for the exchange of
+ delegation information between parent and child.
+
+ Using the DNS itself as the source for the actual DNSKEY material,
+ with an off-band check on the validity of the DNSKEY, has the benefit
+ that it reduces the chances of user error. A parental DNSKEY download
+ tool can make use of the SEP bit [4] to select the proper key from a
+ DNSSEC keyset; thereby reducing the chance that the wrong DNSKEY is
+ sent. It can validate the self-signature over a key; thereby
+ verifying the ownership of the private key material. Fetching the
+ DNSKEY from the DNS ensures that the child will not become bogus once
+ the parent publishes the DS RR indicating the child is secure.
+
+ Note: the off-band verification is still needed when the key-material
+ is fetched by a tool. The parent can not be sure whether the DNSKEY
+ RRs have been spoofed.
+
+5.2 Storing Keys So Hashes Can Be Regenerated
+
+ When designing a registry system one should consider if the DNSKEYs
+ and/or the corresponding DSs are stored. Storing DNSKEYs will help
+ during troubleshooting while the overhead of calculating DS records
+ from them is minimal.
+
+ Having an out-of-band mechanism, such as a Whois database, to find
+ out which keys are used to generate DS Resource Records for specific
+ owners may also help with troubleshooting.
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 16]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+5.3 Security Lameness Checks
+
+ Security Lameness is defined as what happens when a parent has a DS
+ Resource Record pointing to a non-existing DNSKEY RR. During key
+ exchange a parent should make sure that the child's key is actually
+ configured in the DNS before publishing a DS RR in its zone. Failure
+ to do so would render the child's zone being marked as bogus.
+
+ Child zones should be very careful removing DNSKEY material,
+ specifically SEP keys, for which a DS RR exists.
+
+ Once a zone is "security lame" a fix (e.g. by removing a DS RR) will
+ take time to propagate through the DNS.
+
+5.4 DS Signature Validity Period
+
+ Since the DS can be replayed as long as it has a valid signature a
+ short signature validity period over the DS minimises the time a
+ child is vulnerable in the case of a compromise of the child's
+ KSK(s). A signature validity period that is too short introduces the
+ possibility that a zone is marked bogus in case of a configuration
+ error in the signer; there may not be enough time to fix the problems
+ before signatures expire. Something as mundane as operator
+ unavailability during weekends shows the need for DS signature
+ lifetimes longer than 2 days. We recommend the minimum for a DS
+ signature validity period to be a few days.
+
+ The maximum signature lifetime of the DS record depends on how long
+ child zones are willing to be vulnerable after a key compromise. We
+ consider a signature validity period of around one week to be a good
+ compromise between the operational constraints of the parent and
+ minimising damage for the child.
+
+6. Security Considerations
+
+ DNSSEC adds data integrity to the DNS. This document tries to assess
+ considerations to operate a stable and secure DNSSEC service. Not
+ taking into account the 'data propagation' properties in the DNS will
+ cause validation failures and may make secured zones unavailable to
+ security aware resolvers.
+
+7. Acknowledgments
+
+ We, the folk mentioned as authors, only acted as editors. Most of the
+ ideas in this draft were the result of collective efforts during
+ workshops, discussions and try outs.
+
+ At the risk of forgetting individuals who where the original
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 17]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ contributors of the ideas we would like to acknowledge people who
+ where actively involved in the compilation of this document. In
+ random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson,
+ Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier
+ Courtay, Sam Weiler.
+
+ Emma Bretherick and Adrian Bedford corrected many of the spelling and
+ style issues.
+
+ Kolkman and Gieben take the blame for introducing all miscakes(SIC).
+
+8. References
+
+8.1 Normative References
+
+ [1] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [2] Eastlake, D., "DNS Security Operational Considerations", RFC
+ 2541, March 1999.
+
+ [3] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+
+ [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key
+ (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work
+ in progress), February 2003.
+
+8.2 Informative References
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
+ 2308, March 1998.
+
+ [7] Gudmundsson, O., "Delegation Signer Resource Record",
+ draft-ietf-dnsext-delegation-signer-13 (work in progress), March
+ 2003.
+
+ [8] Arends, R., "Protocol Modifications for the DNS Security
+ Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in
+ progress), March 2003.
+
+ [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes",
+ The Journal of Cryptology 14 (255-293), 2001.
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 18]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+Authors' Addresses
+
+ Olaf M. Kolkman
+ RIPE NCC
+ Singel 256
+ Amsterdam 1016 AB
+ The Netherlands
+
+ Phone: +31 20 535 4444
+ EMail: olaf@ripe.net
+ URI: http://www.ripe.net/
+
+
+ Miek Gieben
+ NLnet Labs
+ Kruislaan 419
+ Amsterdam 1098 VA
+ The Netherlands
+
+ EMail: miek@nlnetlabs.nl
+ URI: http://www.nlnetlabs.nl
+
+Appendix A. Terminology
+
+ In this document there is some jargon used that is defined in other
+ documents. In most cases we have not copied the text from the
+ documents defining the terms but given a more elaborate explanation
+ of the meaning. Note that these explanations should not be seen as
+ authoritative.
+
+ Private and Public Keys: DNSSEC secures the DNS through the use of
+ public key cryptography. Public key cryptography is based on the
+ existence of two keys, a public key and a private key. The public
+ keys are published in the DNS by use of the DNSKEY Resource Record
+ (DNSKEY RR). Private keys should remain private i.e. should not be
+ exposed to parties not-authorised to do the actual signing.
+ Signer: The system that has access to the private key material and
+ signs the Resource Record sets in a zone. A signer may be
+ configured to sign only parts of the zone e.g. only those RRsets
+ for which existing signatures are about to expire.
+ KSK: A Key-Signing Key (KSK) is a key that is used exclusively for
+ signing the apex keyset. The fact that a key is a KSK is only
+ relevant to the signing tool.
+ ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all
+ data in a zone. The fact that a key is a ZSK is only relevant to
+ the signing tool.
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 19]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ SEP Key: A KSK that has a parental DS record pointing to it. Note:
+ this is not enforced in the protocol. A SEP Key with no parental
+ DS is security lame.
+ Anchored Key: A DNSKEY configured in resolvers around the globe. This
+ Key is hard to update, hence the term anchored.
+ Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked
+ "Bogus" when a signature of a RRset does not validate against the
+ DNSKEY. Even if the key itself was not marked Bogus. A cache may
+ choose to cache Bogus data for various reasons.
+ Singing the Zone File: The term used for the event where an
+ administrator joyfully signs its zone file while producing melodic
+ sound patterns.
+ Zone Administrator: The 'role' that is responsible for signing a zone
+ and publishing it on the primary authoritative server.
+
+Appendix B. Zone-signing Key Rollover Howto
+
+ Using the pre-published signature scheme and the most conservative
+ method to assure oneself that data does not live in distant caches
+ here follows the "HOWTO". [WES: has some comments about this]
+ Key notation:
+ Step 0: The preparation: Create two keys and publish both in your
+ keyset. Mark one of the keys as "active" and the other as
+ "published". Use the "active" key for signing your zone data.
+ Store the private part of the "published" key, preferably
+ off-line.
+ Step 1: Determine expiration: At the beginning of the rollover make a
+ note of the highest expiration time of signatures in your zone
+ file created with the current key marked as "active".
+ Wait until the expiration time marked in Step 1 has passed
+ Step 2: Then start using the key that was marked as "published" to
+ sign your data i.e. mark it as "active". Stop using the key that
+ was marked as "active", mark it as "rolled".
+ Step 3: It is safe to engage in a new rollover (Step 1) after at
+ least one "signature validity period".
+
+Appendix C. Typographic Conventions
+
+ The following typographic conventions are used in this document:
+ Key notation: A key is denoted by KEYx, where x is a number, x could
+ be thought of as the key id.
+ RRset notations: RRs are only denoted by the type. All other
+ information - owner, class, rdata and TTL - is left out. Thus:
+ example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a
+ list of RRs. A example of this would be: A1,A2, specifying the
+ RRset containing two A records. This could again be abbreviated to
+ just: A.
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 20]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ Signature notation: Signatures are denoted as RRSIGx(RRset), which
+ means that RRset is signed with DNSKEYx.
+ Zone representation: Using the above notation we have simplified the
+ representation of a signed zone by leaving out all unnecessary
+ details such as the names and by representing all data by "SOAx"
+ SOA representation: SOA's are represented as SOAx, where x is the
+ serial number.
+ Using this notation the following zone :
+
+
+ example.net. 600 IN SOA ns.example.net. ernie.example.net. (
+ 10 ; serial
+ 450 ; refresh (7 minutes 30 seconds)
+ 600 ; retry (10 minutes)
+ 345600 ; expire (4 days)
+ 300 ; minimum (5 minutes)
+ )
+ 600 RRSIG SOA 5 2 600 20130522213204 (
+ 20130422213204 14 example.net.
+ cmL62SI6iAX46xGNQAdQ... )
+ 600 NS a.iana-servers.net.
+ 600 NS b.iana-servers.net.
+ 600 RRSIG NS 5 2 600 20130507213204 (
+ 20130407213204 14 example.net.
+ SO5epiJei19AjXoUpFnQ ... )
+ 3600 DNSKEY 256 3 5 (
+ EtRB9MP5/AvOuVO0I8XDxy0...
+ ) ; key id = 14
+ 3600 DNSKEY 256 3 5 (
+ gsPW/Yy19GzYIY+Gnr8HABU...
+ ) ; key id = 15
+ 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
+ 20130422213204 14 example.net.
+ J4zCe8QX4tXVGjV4e1r9... )
+ 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
+ 20130422213204 15 example.net.
+ keVDCOpsSeDReyV6O... )
+ 600 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC
+ 600 RRSIG NSEC 5 2 600 20130507213204 (
+ 20130407213204 14 example.net.
+ obj3HEp1GjnmhRjX... )
+ a.example.net. 600 IN TXT "A label"
+ 600 RRSIG TXT 5 3 600 20130507213204 (
+ 20130407213204 14 example.net.
+ IkDMlRdYLmXH7QJnuF3v... )
+ 600 NSEC b.example.com. TXT RRSIG NSEC
+ 600 RRSIG NSEC 5 3 600 20130507213204 (
+ 20130407213204 14 example.net.
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 21]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ bZMjoZ3bHjnEz0nIsPMM... )
+
+ ...
+
+
+ is reduced to the following represenation:
+
+ SOA10
+ RRSIG14(SOA10)
+
+ DNSKEY14
+ DNSKEY15
+
+ RRSIG14(KEY)
+ RRSIG15(KEY)
+
+ The rest of the zone data has the same signature as the SOA record,
+ i.e a RRSIG created with DNSKEY 14.
+
+Appendix D. Document Details and Changes
+
+ This section is to be removed by the RFC editor if and when the
+ document is published.
+
+ $Header: /var/cvs/dnssec-key/
+ draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12
+ 08:29:11 dnssec Exp $
+
+D.1 draft-ietf-dnsop-dnssec-operational-practices-00
+
+ Submission as working group document. This document is a modified and
+ updated version of draft-kolkman-dnssec-operational-practices-00.
+
+D.2 draft-ietf-dnsop-dnssec-operational-practices-01
+
+ changed the definition of "Bogus" to reflect the one in the protocol
+ draft.
+
+ Bad to Bogus
+
+ Style and spelling corrections
+
+ KSK - SEP mapping made explicit.
+
+ Updates from Sam Weiler added
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 22]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 23]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 24]
+
+
diff --git a/doc/draft/update b/doc/draft/update index 766f15b0..6ac20904 100644 --- a/doc/draft/update +++ b/doc/draft/update @@ -1,4 +1,5 @@ #!/bin/sh +commit= for i do z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'` @@ -34,9 +35,12 @@ do then rm $old cvs delete $old - else - old= + commit="$commit $old" fi - cvs commit -m "new draft" $i $old + commit="$commit $i" fi done +if test -n "$commit" +then + cvs commit -m "new draft" $commit +fi diff --git a/doc/misc/options b/doc/misc/options index 8eec93f4..f77e4940 100644 --- a/doc/misc/options +++ b/doc/misc/options @@ -82,7 +82,7 @@ options { root-delegation-only [ exclude { <quoted_string>; ... } ]; disable-algorithms <string> { <string>; ... }; dnssec-enable <boolean>; - dnssec-lookaside <string>; + dnssec-lookaside <string> trust-anchor <string>; dnssec-must-be-secure <string> <boolean>; allow-query { <address_match_element>; ... }; allow-transfer { <address_match_element>; ... }; @@ -262,7 +262,7 @@ view <string> <optional_class> { root-delegation-only [ exclude { <quoted_string>; ... } ]; disable-algorithms <string> { <string>; ... }; dnssec-enable <boolean>; - dnssec-lookaside <string>; + dnssec-lookaside <string> trust-anchor <string>; dnssec-must-be-secure <string> <boolean>; allow-query { <address_match_element>; ... }; allow-transfer { <address_match_element>; ... }; diff --git a/lib/bind/api b/lib/bind/api index 612fc85e..815c8f55 100644 --- a/lib/bind/api +++ b/lib/bind/api @@ -1,3 +1,3 @@ LIBINTERFACE = 3 -LIBREVISION = 3 +LIBREVISION = 4 LIBAGE = 0 diff --git a/lib/bind/configure b/lib/bind/configure index dd7cddb6..dd7cddb6 100644..100755 --- a/lib/bind/configure +++ b/lib/bind/configure diff --git a/lib/bind/mkinstalldirs b/lib/bind/mkinstalldirs index 74a611ae..74a611ae 100644..100755 --- a/lib/bind/mkinstalldirs +++ b/lib/bind/mkinstalldirs diff --git a/lib/bind/resolv/res_mkupdate.c b/lib/bind/resolv/res_mkupdate.c index f15c6137..aac95e59 100644 --- a/lib/bind/resolv/res_mkupdate.c +++ b/lib/bind/resolv/res_mkupdate.c @@ -21,7 +21,7 @@ */ #if !defined(lint) && !defined(SABER) -static const char rcsid[] = "$Id: res_mkupdate.c,v 1.1.2.1.4.2 2004/03/16 12:34:19 marka Exp $"; +static const char rcsid[] = "$Id: res_mkupdate.c,v 1.1.2.1.4.3 2004/06/03 04:44:48 marka Exp $"; #endif /* not lint */ #include "port_before.h" @@ -350,13 +350,13 @@ res_nmkupdate(res_state statp, ns_updrec *rrecp_in, u_char *buf, int buflen) { bm[i] = 0; while (getword_str(buf2, sizeof buf2, &startp, endp)) { - if ((n1 = res_servicenumber(buf2)) <= 0) + if ((n = res_servicenumber(buf2)) <= 0) return (-1); - if (n1 < MAXPORT) { - bm[n1/8] |= (0x80>>(n1%8)); - if (n1 > maxbm) - maxbm = n1; + if (n < MAXPORT) { + bm[n/8] |= (0x80>>(n%8)); + if ((unsigned)n > maxbm) + maxbm = n; } else return (-1); } diff --git a/lib/bind/resolv/res_send.c b/lib/bind/resolv/res_send.c index f38979d3..187270c1 100644 --- a/lib/bind/resolv/res_send.c +++ b/lib/bind/resolv/res_send.c @@ -70,7 +70,7 @@ #if defined(LIBC_SCCS) && !defined(lint) static const char sccsid[] = "@(#)res_send.c 8.1 (Berkeley) 6/4/93"; -static const char rcsid[] = "$Id: res_send.c,v 1.5.2.2.4.3 2004/04/12 06:54:59 marka Exp $"; +static const char rcsid[] = "$Id: res_send.c,v 1.5.2.2.4.4 2004/06/03 04:40:16 marka Exp $"; #endif /* LIBC_SCCS and not lint */ /* @@ -656,7 +656,7 @@ send_vc(res_state statp, len = INT16SZ; while ((n = read(statp->_vcsock, (char *)cp, (int)len)) > 0) { cp += n; - if ((len -= n) <= 0) + if ((len -= n) == 0) break; } if (n <= 0) { diff --git a/lib/bind9/api b/lib/bind9/api index 7931195a..ae2943dd 100644 --- a/lib/bind9/api +++ b/lib/bind9/api @@ -1,3 +1,3 @@ LIBINTERFACE = 0 -LIBREVISION = 2 +LIBREVISION = 3 LIBAGE = 0 diff --git a/lib/bind9/check.c b/lib/bind9/check.c index 05212917..862f05c1 100644 --- a/lib/bind9/check.c +++ b/lib/bind9/check.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: check.c,v 1.37.6.26 2004/05/17 05:58:38 marka Exp $ */ +/* $Id: check.c,v 1.37.6.27 2004/06/04 02:33:00 marka Exp $ */ #include <config.h> @@ -280,6 +280,39 @@ disabled_algorithms(cfg_obj_t *disabled, isc_log_t *logctx) { } static isc_result_t +nameexist(cfg_obj_t *obj, const char *name, int value, isc_symtab_t *symtab, + const char *fmt, isc_log_t *logctx, isc_mem_t *mctx) +{ + char *key; + const char *file; + unsigned int line; + isc_result_t result; + isc_symvalue_t symvalue; + + key = isc_mem_strdup(mctx, name); + if (key == NULL) + return (ISC_R_NOMEMORY); + symvalue.as_pointer = obj; + result = isc_symtab_define(symtab, key, value, symvalue, + isc_symexists_reject); + if (result == ISC_R_EXISTS) { + RUNTIME_CHECK(isc_symtab_lookup(symtab, key, value, + &symvalue) == ISC_R_SUCCESS); + file = cfg_obj_file(symvalue.as_pointer); + line = cfg_obj_line(symvalue.as_pointer); + + if (file == NULL) + file = "<unknown file>"; + cfg_obj_log(obj, logctx, ISC_LOG_ERROR, fmt, key, file, line); + isc_mem_free(mctx, key); + result = ISC_R_EXISTS; + } else if (result != ISC_R_SUCCESS) { + isc_mem_free(mctx, key); + } + return (result); +} + +static isc_result_t mustbesecure(cfg_obj_t *secure, isc_symtab_t *symtab, isc_log_t *logctx, isc_mem_t *mctx) { @@ -290,9 +323,6 @@ mustbesecure(cfg_obj_t *secure, isc_symtab_t *symtab, isc_log_t *logctx, dns_name_t *name; isc_buffer_t b; isc_result_t result = ISC_R_SUCCESS; - isc_result_t tresult; - isc_symvalue_t symvalue; - char *key; dns_fixedname_init(&fixed); name = dns_fixedname_name(&fixed); @@ -300,42 +330,16 @@ mustbesecure(cfg_obj_t *secure, isc_symtab_t *symtab, isc_log_t *logctx, str = cfg_obj_asstring(obj); isc_buffer_init(&b, str, strlen(str)); isc_buffer_add(&b, strlen(str)); - tresult = dns_name_fromtext(name, &b, dns_rootname, ISC_FALSE, NULL); - if (tresult != ISC_R_SUCCESS) { + result = dns_name_fromtext(name, &b, dns_rootname, ISC_FALSE, NULL); + if (result != ISC_R_SUCCESS) { cfg_obj_log(obj, logctx, ISC_LOG_ERROR, "bad domain name '%s'", str); - result = tresult; } else { - dns_name_format(name, namebuf, sizeof(namebuf)); - key = isc_mem_strdup(mctx, namebuf); - if (key == NULL) - return (ISC_R_NOMEMORY); - symvalue.as_pointer = secure; - tresult = isc_symtab_define(symtab, key, 1, symvalue, - isc_symexists_reject); - if (tresult == ISC_R_EXISTS) { - const char *file; - unsigned int line; - - RUNTIME_CHECK(isc_symtab_lookup(symtab, key, 1, - &symvalue) == ISC_R_SUCCESS); - isc_mem_free(mctx, key); - file = cfg_obj_file(symvalue.as_pointer); - line = cfg_obj_line(symvalue.as_pointer); - - if (file == NULL) - file = "<unknown file>"; - - cfg_obj_log(secure, logctx, ISC_LOG_ERROR, - "dnssec-must-be-secure '%s': already " - "exists previous definition: %s:%u", - namebuf, file, line); - result = tresult; - } else if (tresult != ISC_R_SUCCESS) { - isc_mem_free(mctx, key); - result = tresult; - } + result = nameexist(secure, namebuf, 1, symtab, + "dnssec-must-be-secure '%s': already " + "exists previous definition: %s:%u", + logctx, mctx); } return (result); } @@ -353,6 +357,7 @@ check_options(cfg_obj_t *options, isc_log_t *logctx, isc_mem_t *mctx) { unsigned int i; cfg_obj_t *obj = NULL; cfg_listelt_t *element; + isc_symtab_t *symtab = NULL; static intervaltable intervals[] = { { "cleaning-interval", 60, 28 * 24 * 60 }, /* 28 days */ @@ -458,21 +463,70 @@ check_options(cfg_obj_t *options, isc_log_t *logctx, isc_mem_t *mctx) { obj = NULL; (void)cfg_map_get(options, "dnssec-lookaside", &obj); if (obj != NULL) { - dns_fixedname_t fixedname; - const char *dlv; - isc_buffer_t b; - - dlv = cfg_obj_asstring(obj); - dns_fixedname_init(&fixedname); - isc_buffer_init(&b, dlv, strlen(dlv)); - isc_buffer_add(&b, strlen(dlv)); - tresult = dns_name_fromtext(dns_fixedname_name(&fixedname), &b, - dns_rootname, ISC_TRUE, NULL); - if (tresult != ISC_R_SUCCESS) { - cfg_obj_log(obj, logctx, ISC_LOG_ERROR, - "bad domain name '%s'", dlv); + tresult = isc_symtab_create(mctx, 100, freekey, mctx, + ISC_TRUE, &symtab); + if (tresult != ISC_R_SUCCESS) result = tresult; + for (element = cfg_list_first(obj); + element != NULL; + element = cfg_list_next(element)) + { + dns_fixedname_t fixedname; + dns_name_t *name; + const char *dlv; + isc_buffer_t b; + + obj = cfg_listelt_value(element); + + dlv = cfg_obj_asstring(cfg_tuple_get(obj, "domain")); + dns_fixedname_init(&fixedname); + name = dns_fixedname_name(&fixedname); + isc_buffer_init(&b, dlv, strlen(dlv)); + isc_buffer_add(&b, strlen(dlv)); + tresult = dns_name_fromtext(name, &b, dns_rootname, + ISC_TRUE, NULL); + if (tresult != ISC_R_SUCCESS) { + cfg_obj_log(obj, logctx, ISC_LOG_ERROR, + "bad domain name '%s'", dlv); + result = tresult; + } + if (symtab != NULL) { + tresult = nameexist(obj, dlv, 1, symtab, + "dnssec-lookaside '%s': " + "already exists previous " + "definition: %s:%u", + logctx, mctx); + if (tresult != ISC_R_SUCCESS && + result == ISC_R_SUCCESS) + result = tresult; + } + /* + * XXXMPA to be removed when multiple lookaside + * namespaces are supported. + */ + if (!dns_name_equal(dns_rootname, name)) { + cfg_obj_log(obj, logctx, ISC_LOG_ERROR, + "dnssec-lookaside '%s': " + "non-root not yet supported", dlv); + if (result == ISC_R_SUCCESS) + result = ISC_R_FAILURE; + } + dlv = cfg_obj_asstring(cfg_tuple_get(obj, + "trust-anchor")); + dns_fixedname_init(&fixedname); + isc_buffer_init(&b, dlv, strlen(dlv)); + isc_buffer_add(&b, strlen(dlv)); + tresult = dns_name_fromtext(name, &b, dns_rootname, + ISC_TRUE, NULL); + if (tresult != ISC_R_SUCCESS) { + cfg_obj_log(obj, logctx, ISC_LOG_ERROR, + "bad domain name '%s'", dlv); + if (result == ISC_R_SUCCESS) + result = tresult; + } } + if (symtab != NULL) + isc_symtab_destroy(&symtab); } /* @@ -643,7 +697,6 @@ check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *config, isc_symtab_t *symtab, unsigned int ztype; cfg_obj_t *zoptions; cfg_obj_t *obj = NULL; - isc_symvalue_t symvalue; isc_result_t result = ISC_R_SUCCESS; isc_result_t tresult; unsigned int i; @@ -758,48 +811,22 @@ check_zoneconf(cfg_obj_t *zconfig, cfg_obj_t *config, isc_symtab_t *symtab, dns_fixedname_init(&fixedname); isc_buffer_init(&b, zname, strlen(zname)); isc_buffer_add(&b, strlen(zname)); - result = dns_name_fromtext(dns_fixedname_name(&fixedname), &b, + tresult = dns_name_fromtext(dns_fixedname_name(&fixedname), &b, dns_rootname, ISC_TRUE, NULL); if (result != ISC_R_SUCCESS) { cfg_obj_log(zconfig, logctx, ISC_LOG_ERROR, "zone '%s': is not a valid name", zname); - result = ISC_R_FAILURE; + tresult = ISC_R_FAILURE; } else { char namebuf[DNS_NAME_FORMATSIZE]; - char *key; dns_name_format(dns_fixedname_name(&fixedname), namebuf, sizeof(namebuf)); - key = isc_mem_strdup(mctx, namebuf); - if (key == NULL) - return (ISC_R_NOMEMORY); - symvalue.as_pointer = zconfig; - tresult = isc_symtab_define(symtab, key, - ztype == HINTZONE ? 1 : 2, - symvalue, isc_symexists_reject); - if (tresult == ISC_R_EXISTS) { - const char *file; - unsigned int line; - - RUNTIME_CHECK(isc_symtab_lookup(symtab, key, - ztype == HINTZONE ? 1 : 2, - &symvalue) == ISC_R_SUCCESS); - isc_mem_free(mctx, key); - file = cfg_obj_file(symvalue.as_pointer); - line = cfg_obj_line(symvalue.as_pointer); - - if (file == NULL) - file = "<unknown file>"; - cfg_obj_log(zconfig, logctx, ISC_LOG_ERROR, - "zone '%s': already exists " - "previous definition: %s:%u", - zname, file, line); - result = ISC_R_FAILURE; - } else if (tresult != ISC_R_SUCCESS) { - isc_mem_free(mctx, key); - - return (tresult); - } + tresult = nameexist(zconfig, namebuf, ztype == HINTZONE ? 1 : 2, + symtab, "zone '%s': already exists " + "previous definition: %s:%u", logctx, mctx); + if (tresult != ISC_R_SUCCESS) + result = tresult; } /* diff --git a/lib/dns/api b/lib/dns/api index 49b39c32..ac097210 100644 --- a/lib/dns/api +++ b/lib/dns/api @@ -1,3 +1,3 @@ LIBINTERFACE = 15 -LIBREVISION = 0 +LIBREVISION = 1 LIBAGE = 0 diff --git a/lib/dns/dnssec.c b/lib/dns/dnssec.c index 6d78ee42..34ff3d3a 100644 --- a/lib/dns/dnssec.c +++ b/lib/dns/dnssec.c @@ -16,7 +16,7 @@ */ /* - * $Id: dnssec.c,v 1.69.2.5.2.6 2004/03/08 21:06:26 marka Exp $ + * $Id: dnssec.c,v 1.69.2.5.2.7 2004/06/11 00:30:54 marka Exp $ */ @@ -134,6 +134,8 @@ dns_dnssec_keyfromrdata(dns_name_t *name, dns_rdata_t *rdata, isc_mem_t *mctx, INSIST(mctx != NULL); INSIST(key != NULL); INSIST(*key == NULL); + REQUIRE(rdata->type == dns_rdatatype_key || + rdata->type == dns_rdatatype_dnskey); dns_rdata_toregion(rdata, &r); isc_buffer_init(&b, r.base, r.length); diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c index df44fa08..a0e5ab51 100644 --- a/lib/dns/rbtdb.c +++ b/lib/dns/rbtdb.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rbtdb.c,v 1.168.2.11.2.15 2004/05/14 05:06:38 marka Exp $ */ +/* $Id: rbtdb.c,v 1.168.2.11.2.16 2004/05/23 11:07:23 marka Exp $ */ /* * Principal Author: Bob Halley @@ -1061,9 +1061,13 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) { * isn't being used by anyone, we can clean * it up. */ - if (rbtdb->current_version->references == 0) + if (rbtdb->current_version->references == 0) { cleanup_version = rbtdb->current_version; + APPENDLIST(version->changed_list, + cleanup_version->changed_list, + link); + } /* * Become the current version. */ @@ -1076,6 +1080,7 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) { * We're rolling back this transaction. */ cleanup_list = version->changed_list; + ISC_LIST_INIT(version->changed_list); rollback = ISC_TRUE; cleanup_version = version; rbtdb->future_version = NULL; @@ -1096,6 +1101,7 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) { if (least_greater == NULL) least_greater = rbtdb->current_version; + INSIST(version->serial < least_greater->serial); /* * Is this the least open version? */ @@ -1116,16 +1122,19 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) { version->changed_list, link); } - } + } else if (version->serial == rbtdb->least_serial) + INSIST(EMPTY(version->changed_list)); UNLINK(rbtdb->open_versions, version, link); } } least_serial = rbtdb->least_serial; UNLOCK(&rbtdb->lock); - if (cleanup_version != NULL) + if (cleanup_version != NULL) { + INSIST(EMPTY(cleanup_version->changed_list)); isc_mem_put(rbtdb->common.mctx, cleanup_version, sizeof(*cleanup_version)); + } if (!EMPTY(cleanup_list)) { for (changed = HEAD(cleanup_list); diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c index bda01480..a24e7b36 100644 --- a/lib/dns/resolver.c +++ b/lib/dns/resolver.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.c,v 1.218.2.18.4.37 2004/05/14 05:06:39 marka Exp $ */ +/* $Id: resolver.c,v 1.218.2.18.4.38 2004/06/07 03:24:57 marka Exp $ */ #include <config.h> @@ -4716,6 +4716,9 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) { isc_boolean_t bucket_empty = ISC_FALSE; isc_boolean_t locked = ISC_FALSE; unsigned int bucketnum; + dns_rdataset_t nameservers; + dns_fixedname_t fixed; + dns_name_t *domain; REQUIRE(event->ev_type == DNS_EVENT_FETCHDONE); fevent = (dns_fetchevent_t *)event; @@ -4731,15 +4734,17 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) { if (fevent->db != NULL) dns_db_detach(&fevent->db); - dns_resolver_destroyfetch(&fctx->nsfetch); + dns_rdataset_init(&nameservers); bucketnum = fctx->bucketnum; - if (fevent->result == ISC_R_CANCELED) + if (fevent->result == ISC_R_CANCELED) { + dns_resolver_destroyfetch(&fctx->nsfetch); fctx_done(fctx, ISC_R_CANCELED); - else if (fevent->result == ISC_R_SUCCESS) { + } else if (fevent->result == ISC_R_SUCCESS) { FCTXTRACE("resuming DS lookup"); + dns_resolver_destroyfetch(&fctx->nsfetch); if (dns_rdataset_isassociated(&fctx->nameservers)) dns_rdataset_disassociate(&fctx->nameservers); dns_rdataset_clone(fevent->rdataset, &fctx->nameservers); @@ -4758,22 +4763,29 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) { } else { unsigned int n; + /* + * Retrieve state from fctx->nsfetch before we destroy it. + */ + dns_fixedname_init(&fixed); + domain = dns_fixedname_name(&fixed); + dns_name_copy(&fctx->nsfetch->private->domain, domain, NULL); + dns_rdataset_clone(&fctx->nsfetch->private->nameservers, + &nameservers); + dns_resolver_destroyfetch(&fctx->nsfetch); + if (dns_name_equal(&fctx->nsname, domain)) { + fctx_done(fctx, DNS_R_SERVFAIL); + goto cleanup; + } n = dns_name_countlabels(&fctx->nsname); dns_name_getlabelsequence(&fctx->nsname, 1, n - 1, &fctx->nsname); - if (dns_name_equal(&fctx->nsname, &fctx->domain)) { - fctx_done(fctx, DNS_R_SERVFAIL); - goto cleanup; - } if (dns_rdataset_isassociated(fevent->rdataset)) dns_rdataset_disassociate(fevent->rdataset); FCTXTRACE("continuing to look for parent's NS records"); result = dns_resolver_createfetch(fctx->res, &fctx->nsname, - dns_rdatatype_ns, - &fctx->domain, - &fctx->nameservers, NULL, - 0, task, + dns_rdatatype_ns, domain, + &nameservers, NULL, 0, task, resume_dslookup, fctx, &fctx->nsrrset, NULL, &fctx->nsfetch); @@ -4787,6 +4799,8 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) { } cleanup: + if (dns_rdataset_isassociated(&nameservers)) + dns_rdataset_disassociate(&nameservers); if (dns_rdataset_isassociated(fevent->rdataset)) dns_rdataset_disassociate(fevent->rdataset); INSIST(fevent->sigrdataset == NULL); diff --git a/lib/dns/sec/dst/dst_api.c b/lib/dns/sec/dst/dst_api.c index 39415a90..f3adedc1 100644 --- a/lib/dns/sec/dst/dst_api.c +++ b/lib/dns/sec/dst/dst_api.c @@ -18,7 +18,7 @@ /* * Principal Author: Brian Wellington - * $Id: dst_api.c,v 1.88.2.3.2.12 2004/03/16 05:50:22 marka Exp $ + * $Id: dst_api.c,v 1.88.2.3.2.15 2004/06/16 01:05:01 marka Exp $ */ #include <config.h> @@ -70,6 +70,7 @@ static dst_key_t * get_key_struct(dns_name_t *name, dns_rdataclass_t rdclass, isc_mem_t *mctx); static isc_result_t read_public_key(const char *filename, + int type, isc_mem_t *mctx, dst_key_t **keyp); static isc_result_t write_public_key(const dst_key_t *key, int type, @@ -145,9 +146,11 @@ dst_lib_init(isc_mem_t *mctx, isc_entropy_t *ectx, unsigned int eflags) { RETERR(dst__openssl_init()); RETERR(dst__opensslrsa_init(&dst_t_func[DST_ALG_RSAMD5])); RETERR(dst__opensslrsa_init(&dst_t_func[DST_ALG_RSASHA1])); +#ifdef HAVE_OPENSSL_DSA RETERR(dst__openssldsa_init(&dst_t_func[DST_ALG_DSA])); - RETERR(dst__openssldh_init(&dst_t_func[DST_ALG_DH])); #endif + RETERR(dst__openssldh_init(&dst_t_func[DST_ALG_DH])); +#endif /* OPENSSL */ #ifdef GSSAPI RETERR(dst__gssapi_init(&dst_t_func[DST_ALG_GSSAPI])); #endif @@ -389,7 +392,7 @@ dst_key_fromnamedfile(const char *filename, int type, isc_mem_t *mctx, REQUIRE(mctx != NULL); REQUIRE(keyp != NULL && *keyp == NULL); - result = read_public_key(filename, mctx, &pubkey); + result = read_public_key(filename, type, mctx, &pubkey); if (result != ISC_R_SUCCESS) return (result); @@ -823,7 +826,9 @@ get_key_struct(dns_name_t *name, unsigned int alg, * Reads a public key from disk */ static isc_result_t -read_public_key(const char *filename, isc_mem_t *mctx, dst_key_t **keyp) { +read_public_key(const char *filename, int type, + isc_mem_t *mctx, dst_key_t **keyp) +{ u_char rdatabuf[DST_KEY_MAXSIZE]; isc_buffer_t b; dns_fixedname_t name; @@ -838,7 +843,7 @@ read_public_key(const char *filename, isc_mem_t *mctx, dst_key_t **keyp) { isc_lexspecials_t specials; isc_uint32_t ttl; isc_result_t result; - dns_rdatatype_t type; + dns_rdatatype_t keytype; newfilenamelen = strlen(filename) + 5; newfilename = isc_mem_get(mctx, newfilenamelen); @@ -911,14 +916,20 @@ read_public_key(const char *filename, isc_mem_t *mctx, dst_key_t **keyp) { BADTOKEN(); if (strcasecmp(DST_AS_STR(token), "DNSKEY") == 0) - type = dns_rdatatype_dnskey; + keytype = dns_rdatatype_dnskey; else if (strcasecmp(DST_AS_STR(token), "KEY") == 0) - type = dns_rdatatype_key; /* SIG(0) */ + keytype = dns_rdatatype_key; /* SIG(0), TKEY */ else BADTOKEN(); + if (((type & DST_TYPE_KEY) != 0 && keytype != dns_rdatatype_key) || + ((type & DST_TYPE_KEY) == 0 && keytype != dns_rdatatype_dnskey)) { + ret = DST_R_BADKEYTYPE; + goto cleanup; + } + isc_buffer_init(&b, rdatabuf, sizeof(rdatabuf)); - ret = dns_rdata_fromtext(&rdata, rdclass, type, lex, NULL, + ret = dns_rdata_fromtext(&rdata, rdclass, keytype, lex, NULL, ISC_FALSE, mctx, &b, NULL); if (ret != ISC_R_SUCCESS) goto cleanup; @@ -1136,10 +1147,12 @@ algorithm_status(unsigned int alg) { if (dst_algorithm_supported(alg)) return (ISC_R_SUCCESS); +#ifndef OPENSSL if (alg == DST_ALG_RSAMD5 || alg == DST_ALG_RSASHA1 || alg == DST_ALG_DSA || alg == DST_ALG_DH || alg == DST_ALG_HMACMD5) return (DST_R_NOCRYPTO); +#endif return (DST_R_UNSUPPORTEDALG); } diff --git a/lib/dns/sec/dst/dst_result.c b/lib/dns/sec/dst/dst_result.c index da31c403..d6c372f6 100644 --- a/lib/dns/sec/dst/dst_result.c +++ b/lib/dns/sec/dst/dst_result.c @@ -17,7 +17,7 @@ /* * Principal Author: Brian Wellington - * $Id: dst_result.c,v 1.18.2.1.8.1 2004/03/06 08:14:21 marka Exp $ + * $Id: dst_result.c,v 1.18.2.1.8.2 2004/06/11 00:30:55 marka Exp $ */ #include <config.h> @@ -49,6 +49,7 @@ static const char *text[DST_R_NRESULTS] = { "not a key that can compute a secret", /* 17 */ "failure computing a shared secret", /* 18 */ "no randomness available", /* 19 */ + "bad key type" /* 20 */ }; #define DST_RESULT_RESULTSET 2 diff --git a/lib/dns/sec/dst/include/dst/dst.h b/lib/dns/sec/dst/include/dst/dst.h index 7a64b723..614971a7 100644 --- a/lib/dns/sec/dst/include/dst/dst.h +++ b/lib/dns/sec/dst/include/dst/dst.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dst.h,v 1.42.2.1.8.5 2004/03/10 02:55:59 marka Exp $ */ +/* $Id: dst.h,v 1.42.2.1.8.6 2004/06/11 00:31:01 marka Exp $ */ #ifndef DST_DST_H #define DST_DST_H 1 @@ -218,6 +218,7 @@ dst_key_fromfile(dns_name_t *name, dns_keytag_t id, unsigned int alg, int type, * "id" is a valid key tag identifier. * "alg" is a supported key algorithm. * "type" is DST_TYPE_PUBLIC, DST_TYPE_PRIVATE, or the bitwise union. + * DST_TYPE_KEY look for a KEY record otherwise DNSKEY * "mctx" is a valid memory context. * "keyp" is not NULL and "*keyp" is NULL. * @@ -240,6 +241,7 @@ dst_key_fromnamedfile(const char *filename, int type, isc_mem_t *mctx, * Requires: * "filename" is not NULL * "type" is DST_TYPE_PUBLIC, DST_TYPE_PRIVATE, or the bitwise union + * DST_TYPE_KEY look for a KEY record otherwise DNSKEY * "mctx" is a valid memory context * "keyp" is not NULL and "*keyp" is NULL. * diff --git a/lib/dns/sec/dst/include/dst/result.h b/lib/dns/sec/dst/include/dst/result.h index bbac21ea..fa5ff39a 100644 --- a/lib/dns/sec/dst/include/dst/result.h +++ b/lib/dns/sec/dst/include/dst/result.h @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: result.h,v 1.20.206.1 2004/03/06 08:14:25 marka Exp $ */ +/* $Id: result.h,v 1.20.206.2 2004/06/11 00:31:01 marka Exp $ */ #ifndef DST_RESULT_H #define DST_RESULT_H 1 @@ -51,8 +51,9 @@ #define DST_R_KEYCANNOTCOMPUTESECRET (ISC_RESULTCLASS_DST + 17) #define DST_R_COMPUTESECRETFAILURE (ISC_RESULTCLASS_DST + 18) #define DST_R_NORANDOMNESS (ISC_RESULTCLASS_DST + 19) +#define DST_R_BADKEYTYPE (ISC_RESULTCLASS_DST + 20) -#define DST_R_NRESULTS 20 /* Number of results */ +#define DST_R_NRESULTS 21 /* Number of results */ ISC_LANG_BEGINDECLS diff --git a/lib/dns/tkey.c b/lib/dns/tkey.c index eb8be5ee..dc49a337 100644 --- a/lib/dns/tkey.c +++ b/lib/dns/tkey.c @@ -16,7 +16,7 @@ */ /* - * $Id: tkey.c,v 1.71.2.1.10.4 2004/03/08 02:07:58 marka Exp $ + * $Id: tkey.c,v 1.71.2.1.10.5 2004/06/11 00:30:54 marka Exp $ */ #include <config.h> @@ -285,7 +285,7 @@ process_dhtkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name, keyname = NULL; dns_message_currentname(msg, DNS_SECTION_ADDITIONAL, &keyname); keyset = NULL; - result = dns_message_findtype(keyname, dns_rdatatype_dnskey, 0, + result = dns_message_findtype(keyname, dns_rdatatype_key, 0, &keyset); if (result != ISC_R_SUCCESS) continue; @@ -333,7 +333,7 @@ process_dhtkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name, RETERR(dst_key_todns(tctx->dhkey, &ourkeybuf)); isc_buffer_usedregion(&ourkeybuf, &ourkeyr); dns_rdata_fromregion(&ourkeyrdata, dns_rdataclass_any, - dns_rdatatype_dnskey, &ourkeyr); + dns_rdatatype_key, &ourkeyr); dns_name_init(&ourname, NULL); dns_name_clone(dst_key_name(tctx->dhkey), &ourname); @@ -877,7 +877,7 @@ dns_tkey_builddhquery(dns_message_t *msg, dst_key_t *key, dns_name_t *name, RETERR(dst_key_todns(key, dynbuf)); isc_buffer_usedregion(dynbuf, &r); dns_rdata_fromregion(rdata, dns_rdataclass_any, - dns_rdatatype_dnskey, &r); + dns_rdatatype_key, &r); dns_message_takebuffer(msg, &dynbuf); dns_name_init(&keyname, NULL); @@ -1049,7 +1049,7 @@ dns_tkey_processdhresponse(dns_message_t *qmsg, dns_message_t *rmsg, ourkeyname = NULL; ourkeyset = NULL; RETERR(dns_message_findname(rmsg, DNS_SECTION_ANSWER, &keyname, - dns_rdatatype_dnskey, 0, &ourkeyname, + dns_rdatatype_key, 0, &ourkeyname, &ourkeyset)); result = dns_message_firstname(rmsg, DNS_SECTION_ANSWER); @@ -1060,7 +1060,7 @@ dns_tkey_processdhresponse(dns_message_t *qmsg, dns_message_t *rmsg, if (dns_name_equal(theirkeyname, ourkeyname)) goto next; theirkeyset = NULL; - result = dns_message_findtype(theirkeyname, dns_rdatatype_dnskey, + result = dns_message_findtype(theirkeyname, dns_rdatatype_key, 0, &theirkeyset); if (result == ISC_R_SUCCESS) { RETERR(dns_rdataset_first(theirkeyset)); diff --git a/lib/dns/validator.c b/lib/dns/validator.c index 1d46229b..c55c8939 100644 --- a/lib/dns/validator.c +++ b/lib/dns/validator.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: validator.c,v 1.91.2.5.8.11 2004/05/14 05:06:40 marka Exp $ */ +/* $Id: validator.c,v 1.91.2.5.8.12 2004/06/11 01:17:36 marka Exp $ */ #include <config.h> @@ -1593,7 +1593,7 @@ dlv_validatezonekey(dns_validator_t *val) { } if (result != ISC_R_SUCCESS) { validator_log(val, ISC_LOG_DEBUG(3), - "no KEY matching DLV"); + "no DNSKEY matching DLV"); continue; } @@ -1628,7 +1628,8 @@ dlv_validatezonekey(dns_validator_t *val) { dns_rdataset_disassociate(&trdataset); if (result == ISC_R_SUCCESS) break; - validator_log(val, ISC_LOG_DEBUG(3), "no SIG matching DLV key"); + validator_log(val, ISC_LOG_DEBUG(3), + "no RRSIG matching DLV key"); } if (result == ISC_R_SUCCESS) { val->event->rdataset->trust = dns_trust_secure; @@ -1877,7 +1878,7 @@ validatezonekey(dns_validator_t *val) { } if (result != ISC_R_SUCCESS) { validator_log(val, ISC_LOG_DEBUG(3), - "no KEY matching DS"); + "no DNSKEY matching DS"); continue; } @@ -1912,7 +1913,8 @@ validatezonekey(dns_validator_t *val) { dns_rdataset_disassociate(&trdataset); if (result == ISC_R_SUCCESS) break; - validator_log(val, ISC_LOG_DEBUG(3), "no SIG matching DS key"); + validator_log(val, ISC_LOG_DEBUG(3), + "no RRSIG matching DS key"); } if (result == ISC_R_SUCCESS) { event->rdataset->trust = dns_trust_secure; @@ -2092,8 +2094,8 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) { * would lead to a query for the zone key, which * would return a negative answer, which would contain * an SOA and an NSEC signed by the missing key, which - * would trigger another query for the KEY (since the - * first one is still in progress), and go into an + * would trigger another query for the DNSKEY (since + * the first one is still in progress), and go into an * infinite loop. Avoid that. */ if (val->event->type == dns_rdatatype_dnskey && diff --git a/lib/dns/zone.c b/lib/dns/zone.c index ce91ede5..e63ca49d 100644 --- a/lib/dns/zone.c +++ b/lib/dns/zone.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.c,v 1.333.2.23.2.45 2004/04/29 01:45:23 marka Exp $ */ +/* $Id: zone.c,v 1.333.2.23.2.46 2004/05/29 00:01:17 marka Exp $ */ #include <config.h> @@ -3618,7 +3618,12 @@ refresh_callback(isc_task_t *task, isc_event_t *event) { dns_message_destroy(&msg); } else if (isc_serial_eq(soa.serial, zone->serial)) { if (zone->masterfile != NULL) { - result = isc_file_settime(zone->masterfile, &now); + result = ISC_R_FAILURE; + if (zone->journal != NULL) + result = isc_file_settime(zone->journal, &now); + if (result != ISC_R_SUCCESS) + result = isc_file_settime(zone->masterfile, + &now); /* Someone removed the file from underneath us! */ if (result == ISC_R_FILENOTFOUND) { LOCK_ZONE(zone); @@ -3986,6 +3991,8 @@ soa_query(isc_task_t *task, isc_event_t *event) { return; skip_master: + if (key != NULL) + dns_tsigkey_detach(&key); zone->curmaster++; if (zone->curmaster < zone->masterscnt) goto again; diff --git a/lib/isc/api b/lib/isc/api index 0ab1e92d..b5b94878 100644 --- a/lib/isc/api +++ b/lib/isc/api @@ -1,3 +1,3 @@ LIBINTERFACE = 10 -LIBREVISION = 1 +LIBREVISION = 2 LIBAGE = 1 diff --git a/lib/isc/log.c b/lib/isc/log.c index e678364e..247b2533 100644 --- a/lib/isc/log.c +++ b/lib/isc/log.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: log.c,v 1.70.2.8.2.10 2004/04/10 04:31:40 marka Exp $ */ +/* $Id: log.c,v 1.70.2.8.2.12 2004/06/11 00:35:38 marka Exp $ */ /* Principal Authors: DCL */ @@ -1140,6 +1140,10 @@ greatest_version(isc_logchannel_t *channel, int *greatestp) { unsigned int basenamelen; isc_dir_t dir; isc_result_t result; + char sep = '/'; +#ifdef _WIN32 + char *basename2; +#endif REQUIRE(channel->type == ISC_LOG_TOFILE); @@ -1147,7 +1151,15 @@ greatest_version(isc_logchannel_t *channel, int *greatestp) { * It is safe to DE_CONST the file.name because it was copied * with isc_mem_strdup in isc_log_createchannel. */ - basename = strrchr(FILE_NAME(channel), '/'); + basename = strrchr(FILE_NAME(channel), sep); +#ifdef _WIN32 + basename2 = strrchr(FILE_NAME(channel), '\\'); + if ((basename != NULL && basename2 != NULL && basename2 > basename) || + (basename == NULL && basename2 != NULL)) { + basename = basename2; + sep = '\\'; + } +#endif if (basename != NULL) { *basename++ = '\0'; dirname = FILE_NAME(channel); @@ -1164,7 +1176,7 @@ greatest_version(isc_logchannel_t *channel, int *greatestp) { * Replace the file separator if it was taken out. */ if (basename != FILE_NAME(channel)) - *(basename - 1) = '/'; + *(basename - 1) = sep; /* * Return if the directory open failed. @@ -1317,8 +1329,11 @@ isc_log_open(isc_logchannel_t *channel) { if (stat(path, &statbuf) == 0) { regular_file = S_ISREG(statbuf.st_mode) ? ISC_TRUE : ISC_FALSE; /* XXXDCL if not regular_file complain? */ - roll = ISC_TF(regular_file && FILE_MAXSIZE(channel) > 0 && - statbuf.st_size >= FILE_MAXSIZE(channel)); + if ((FILE_MAXSIZE(channel) == 0 && + FILE_VERSIONS(channel) != ISC_LOG_ROLLNEVER) || + (FILE_MAXSIZE(channel) > 0 && + statbuf.st_size >= FILE_MAXSIZE(channel))) + roll = regular_file; } else if (errno == ENOENT) regular_file = ISC_TRUE; else diff --git a/lib/isc/result.c b/lib/isc/result.c index 12f767f0..5b0ddd3f 100644 --- a/lib/isc/result.c +++ b/lib/isc/result.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: result.c,v 1.56.2.2.8.6 2004/05/15 03:46:12 jinmei Exp $ */ +/* $Id: result.c,v 1.56.2.2.8.7 2004/06/11 00:31:01 marka Exp $ */ #include <config.h> @@ -125,7 +125,7 @@ register_table(unsigned int base, unsigned int nresults, const char **text, if (table == NULL) return (ISC_R_NOMEMORY); table->base = base; - table->last = base + nresults; + table->last = base + nresults - 1; table->text = text; table->msgcat = msgcat; table->set = set; diff --git a/lib/isccfg/api b/lib/isccfg/api index 1d2759ef..7c378e6e 100644 --- a/lib/isccfg/api +++ b/lib/isccfg/api @@ -1,3 +1,3 @@ LIBINTERFACE = 1 -LIBREVISION = 3 +LIBREVISION = 4 LIBAGE = 0 diff --git a/lib/isccfg/namedconf.c b/lib/isccfg/namedconf.c index b065e99a..2e01b2bf 100644 --- a/lib/isccfg/namedconf.c +++ b/lib/isccfg/namedconf.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: namedconf.c,v 1.21.44.27 2004/04/15 23:56:34 marka Exp $ */ +/* $Id: namedconf.c,v 1.21.44.28 2004/06/04 02:33:01 marka Exp $ */ #include <config.h> @@ -659,6 +659,28 @@ static cfg_type_t cfg_type_mustbesecure = { }; /* + * dnssec-lookaside + */ + +static keyword_type_t trustanchor_kw = { "trust-anchor", &cfg_type_astring }; + +static cfg_type_t cfg_type_trustanchor = { + "trust-anchor", parse_keyvalue, print_keyvalue, doc_keyvalue, + &cfg_rep_string, &trustanchor_kw +}; + +static cfg_tuplefielddef_t lookaside_fields[] = { + { "domain", &cfg_type_astring, 0 }, + { "trust-anchor", &cfg_type_trustanchor, 0 }, + { NULL, NULL, 0 } +}; + +static cfg_type_t cfg_type_lookaside = { + "lookaside", cfg_parse_tuple, cfg_print_tuple, cfg_doc_tuple, + &cfg_rep_tuple, lookaside_fields +}; + +/* * Clauses that can be found within the 'view' statement, * with defaults in the 'options' statement. */ @@ -703,7 +725,7 @@ view_clauses[] = { { "disable-algorithms", &cfg_type_disablealgorithm, CFG_CLAUSEFLAG_MULTI }, { "dnssec-enable", &cfg_type_boolean, 0 }, - { "dnssec-lookaside", &cfg_type_astring, 0 }, + { "dnssec-lookaside", &cfg_type_lookaside, CFG_CLAUSEFLAG_MULTI }, { "dnssec-must-be-secure", &cfg_type_mustbesecure, CFG_CLAUSEFLAG_MULTI }, { NULL, NULL, 0 } @@ -1201,6 +1223,7 @@ controls_clauses[] = { CFG_CLAUSEFLAG_MULTI|CFG_CLAUSEFLAG_NOTIMP }, { NULL, NULL, 0 } }; + static cfg_clausedef_t * controls_clausesets[] = { controls_clauses, diff --git a/mkinstalldirs b/mkinstalldirs index 4992567c..4992567c 100644..100755 --- a/mkinstalldirs +++ b/mkinstalldirs @@ -1,4 +1,4 @@ -# $Id: version,v 1.26.2.17.2.5 2004/05/17 13:28:21 marka Exp $ +# $Id: version,v 1.26.2.17.2.6 2004/06/11 03:36:12 marka Exp $ # # This file must follow /bin/sh rules. It is imported directly via # configure. @@ -6,5 +6,5 @@ MAJORVER=9 MINORVER=3 PATCHVER=0 -RELEASETYPE=beta -RELEASEVER=4 +RELEASETYPE=rc +RELEASEVER=1 |