From 7b78f6665635ed85118352c97ff5a25f5bb242f7 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 30 Jun 2004 05:40:07 +0000 Subject: [PATCH 01/14] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index e8e60c528d..0924ac0d3a 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1681. [placeholderr] rt11742 + 1680. [placeholder] rt11697 1679. [bug] When there was a single nameserver with multiple From c5a84548b24ffac37d0154d8f2f4fea36a3aeb23 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 30 Jun 2004 05:45:35 +0000 Subject: [PATCH 02/14] placeholder --- CHANGES | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CHANGES b/CHANGES index 0924ac0d3a..3b38bc7429 100644 --- a/CHANGES +++ b/CHANGES @@ -1,4 +1,6 @@ -1681. [placeholderr] rt11742 +1682. [placeholder] rt5066a + +1681. [placeholder] rt11742 1680. [placeholder] rt11697 From 85609ef4d72c1af28c07ed20df39f71b3276e72f Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 30 Jun 2004 14:16:06 +0000 Subject: [PATCH 03/14] order should be signed. --- bin/named/query.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/bin/named/query.c b/bin/named/query.c index a1ed7c2004..907fac3556 100644 --- a/bin/named/query.c +++ b/bin/named/query.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: query.c,v 1.260 2004/06/29 00:51:50 marka Exp $ */ +/* $Id: query.c,v 1.261 2004/06/30 14:16:06 marka Exp $ */ #include @@ -1842,12 +1842,13 @@ query_addwildcardproof(ns_client_t *client, dns_db_t *db, dns_fixedname_t wfixed; dns_name_t *wname; dns_dbnode_t *node; - unsigned int options, order; + unsigned int options; unsigned int olabels, nlabels; isc_result_t result; dns_rdata_t rdata = DNS_RDATA_INIT; dns_rdata_nsec_t nsec; isc_boolean_t have_wname; + int order; CTRACE("query_addwildcardproof"); fname = NULL; From 9aa7706900e2451fcd6e44ffe4a45b042ec34cf3 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 30 Jun 2004 23:35:17 +0000 Subject: [PATCH 04/14] 1681. [bug] Only set SO_REUSEADDR when a port is specified in isc_socket_bind(). [RT #11742] --- CHANGES | 3 ++- lib/isc/unix/socket.c | 10 +++++++--- lib/isc/win32/socket.c | 8 ++++++-- 3 files changed, 15 insertions(+), 6 deletions(-) diff --git a/CHANGES b/CHANGES index 3b38bc7429..4d3a1cf68a 100644 --- a/CHANGES +++ b/CHANGES @@ -1,6 +1,7 @@ 1682. [placeholder] rt5066a -1681. [placeholder] rt11742 +1681. [bug] Only set SO_REUSEADDR when a port is specified in + isc_socket_bind(). [RT #11742] 1680. [placeholder] rt11697 diff --git a/lib/isc/unix/socket.c b/lib/isc/unix/socket.c index 4c6734b0cb..ad9f4e6bcb 100644 --- a/lib/isc/unix/socket.c +++ b/lib/isc/unix/socket.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.c,v 1.239 2004/04/19 02:53:05 marka Exp $ */ +/* $Id: socket.c,v 1.240 2004/06/30 23:35:16 marka Exp $ */ #include @@ -2859,8 +2859,12 @@ isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr) { UNLOCK(&sock->lock); return (ISC_R_FAMILYMISMATCH); } - if (setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on, - sizeof(on)) < 0) { + /* + * Only set SO_REUSEADDR when we want a specific port. + */ + if (isc_sockaddr_getport(sockaddr) != (in_port_t)0 && + setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on, + sizeof(on)) < 0) { UNEXPECTED_ERROR(__FILE__, __LINE__, "setsockopt(%d) %s", sock->fd, isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, diff --git a/lib/isc/win32/socket.c b/lib/isc/win32/socket.c index 5d2e8d976d..af18e1117e 100644 --- a/lib/isc/win32/socket.c +++ b/lib/isc/win32/socket.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.c,v 1.33 2004/06/18 01:14:59 marka Exp $ */ +/* $Id: socket.c,v 1.34 2004/06/30 23:35:17 marka Exp $ */ /* This code has been rewritten to take advantage of Windows Sockets * I/O Completion Ports and Events. I/O Completion Ports is ONLY @@ -3225,7 +3225,11 @@ isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr) { UNLOCK(&sock->lock); return (ISC_R_FAMILYMISMATCH); } - if (setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on, + /* + * Only set SO_REUSEADDR when we want a specific port. + */ + if (isc_sockaddr_getport(sockaddr) != (in_port_t)0 && + setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on, sizeof(on)) < 0) { UNEXPECTED_ERROR(__FILE__, __LINE__, "setsockopt(%d) %s", sock->fd, From cf6b36171770dc14b6572003b4e8aeaa22536dd4 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 30 Jun 2004 23:47:48 +0000 Subject: [PATCH 05/14] 1683. [bug] dig +sigchase could leak memory. [RT #11445] --- CHANGES | 2 + bin/dig/dighost.c | 93 ++++++++++++++++++++++++++++------------------- 2 files changed, 57 insertions(+), 38 deletions(-) diff --git a/CHANGES b/CHANGES index 4d3a1cf68a..43f11f7761 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1683. [bug] dig +sigchase could leak memory. [RT #11445] + 1682. [placeholder] rt5066a 1681. [bug] Only set SO_REUSEADDR when a port is specified in diff --git a/bin/dig/dighost.c b/bin/dig/dighost.c index 3ba6ba7ef2..b0d322eb3e 100644 --- a/bin/dig/dighost.c +++ b/bin/dig/dighost.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: dighost.c,v 1.263 2004/06/19 02:23:33 sra Exp $ */ +/* $Id: dighost.c,v 1.264 2004/06/30 23:47:48 marka Exp $ */ /* * Notice to programmers: Do not use this code as an example of how to @@ -208,7 +208,7 @@ isc_result_t prove_nx(dns_message_t * msg, dns_name_t * name, dns_name_t * rdata_name, dns_rdataset_t ** rdataset, dns_rdataset_t ** sigrdataset); -isc_result_t nameFromString( const char *str, dns_name_t *p_ret ); +static void nameFromString(const char *str, dns_name_t *p_ret); int inf_name(dns_name_t * name1, dns_name_t * name2); isc_result_t opentmpkey(isc_mem_t *mctx, const char *file, char **tempp, FILE **fp); @@ -962,6 +962,16 @@ setup_system(void) { #ifdef DIG_SIGCHASE /* Setup the list of messages for +sigchase */ ISC_LIST_INIT(chase_message_list); + ISC_LIST_INIT(chase_message_list2); + dns_name_init(&chase_name, NULL); +#if DIG_SIGCHASE_TD + dns_name_init(&chase_current_name, NULL); + dns_name_init(&chase_authority_name, NULL); +#endif +#if DIG_SIGCHASE_BU + dns_name_init(&chase_signame, NULL); +#endif + #endif } @@ -1259,9 +1269,8 @@ start_lookup(void) { current_lookup->sigchase = ISC_FALSE; goto novalidation; } - result = nameFromString(current_lookup->textname, - &query_name); - check_result(result, "nameFromString"); + dns_name_init(&query_name, NULL); + nameFromString(current_lookup->textname, &query_name); for (i = 0; i< tk_list.nb_tk; i++) { key_name = dst_key_name(tk_list.key[i]); @@ -1320,10 +1329,8 @@ start_lookup(void) { MXNAME); isc_buffer_free(&b); - result = nameFromString(current_lookup - ->textnamesigchase, - &chase_name); - check_result(result, "nameFromString"); + nameFromString(current_lookup->textnamesigchase, + &chase_name); dns_name_init(&chase_authority_name, NULL); } @@ -3136,6 +3143,18 @@ destroy_libs(void) { chase_msg = ISC_LIST_NEXT(chase_msg, link); isc_mem_free(mctx, ptr); } + if (dns_name_dynamic(&chase_name)) + dns_name_free(&chase_name, mctx); +#if DIG_SIGCHASE_TD + if (dns_name_dynamic(&chase_current_name)) + dns_name_free(&chase_current_name, mctx); + if (dns_name_dynamic(&chase_authority_name)) + dns_name_free(&chase_authority_name, mctx); +#endif +#if DIG_SIGCHASE_BU + if (dns_name_dynamic(&chase_signame)) + dns_name_free(&chase_signame, mctx); +#endif debug("Destroy memory"); @@ -3563,28 +3582,29 @@ get_trusted_key(isc_mem_t *mctx) } -isc_result_t -nameFromString( const char *str, dns_name_t *p_ret ) -{ - int len = strlen(str); - int ret; +static void +nameFromString(const char *str, dns_name_t *p_ret) { + size_t len = strlen(str); + isc_result_t result; isc_buffer_t buffer; dns_fixedname_t fixedname; - REQUIRE( p_ret); - REQUIRE( str != NULL ); - isc_buffer_init( &buffer, str, len ); - isc_buffer_add( &buffer, len ); + REQUIRE(p_ret != NULL); + REQUIRE(str != NULL); + + isc_buffer_init(&buffer, str, len); + isc_buffer_add(&buffer, len); dns_fixedname_init(&fixedname); - ret = dns_name_fromtext( dns_fixedname_name(&fixedname), &buffer, - dns_rootname, ISC_TRUE, NULL); - if ( ret != ISC_R_SUCCESS ) return ret; + result = dns_name_fromtext(dns_fixedname_name(&fixedname), &buffer, + dns_rootname, ISC_TRUE, NULL); + check_result(result, "nameFromString"); - dns_name_init(p_ret, NULL ); + if (dns_name_dynamic(p_ret)) + dns_name_free(p_ret, mctx); - ret = dns_name_dup( dns_fixedname_name(&fixedname), mctx, p_ret ); - return ret; + result = dns_name_dup(dns_fixedname_name(&fixedname), mctx, p_ret); + check_result(result, "nameFromString"); } @@ -3607,8 +3627,6 @@ prepare_lookup(dns_name_t *name) lookup->rdtype = lookup->rdtype_sigchase; lookup->rdtypeset = ISC_TRUE; lookup->qrdtype = lookup->qrdtype_sigchase; - - s = ISC_LIST_HEAD(lookup->my_server_list); while (s != NULL) { @@ -3840,11 +3858,11 @@ print_rdataset(dns_name_t * name, dns_rdataset_t *rdataset, isc_mem_t *mctx) void -dup_name(dns_name_t *source, dns_name_t* target, isc_mem_t *mctx) -{ +dup_name(dns_name_t *source, dns_name_t *target, isc_mem_t *mctx) { isc_result_t result; - dns_name_init(target, NULL); + if (dns_name_dynamic(target)) + dns_name_free(target, mctx); result = dns_name_dup(source, mctx, target); check_result(result, "dns_name_dup"); } @@ -4322,7 +4340,7 @@ sigchase_td(dns_message_t * msg) dns_name_init(&tmp_name, NULL); result = child_of_zone(&chase_name, &chase_current_name, &tmp_name); - if (chase_authority_name.labels != 0) + if (dns_name_dynamic(&chase_authority_name)) dns_name_free( &chase_authority_name, mctx); dup_name(&tmp_name, &chase_authority_name, mctx); printf(";; and we try to continue chain of trust" @@ -4406,7 +4424,6 @@ sigchase_td(dns_message_t * msg) have_delegation_ns = ISC_FALSE; delegation_follow = ISC_TRUE; error_message = NULL; - dns_name_free(&chase_current_name, mctx); dup_name(&chase_authority_name, &chase_current_name, mctx); dns_name_free(&chase_authority_name, mctx); return; @@ -4419,6 +4436,7 @@ sigchase_td(dns_message_t * msg) dns_name_t rdata_name; isc_result_t ret = ISC_R_FAILURE; + dns_name_init(&rdata_name, NULL); result = prove_nx(error_message, &chase_name, current_lookup->rdclass_sigchase, current_lookup->rdtype_sigchase, &rdata_name, @@ -4454,10 +4472,9 @@ sigchase_td(dns_message_t * msg) cleanandgo: printf(";; cleanandgo \n"); - dns_name_free(&chase_name, mctx); - if (chase_current_name.labels != 0) + if (dns_name_dynamic(&chase_current_name)) dns_name_free(&chase_current_name, mctx); - if (chase_authority_name.labels != 0) + if (dns_name_dynamic(&chase_authority_name)) dns_name_free(&chase_authority_name, mctx); clean_trustedkey(); return; @@ -4548,7 +4565,7 @@ getneededrr(dns_message_t *msg) if (result == ISC_R_FAILURE) { printf("\n;; RRSIG is missing for continue validation:" " FAILED\n\n"); - if (chase_name.ndata != NULL) + if (dns_name_dynamic(&chase_name)) dns_name_free(&chase_name, mctx); return ISC_R_NOTFOUND; } @@ -4583,7 +4600,7 @@ getneededrr(dns_message_t *msg) printf("\n;; DNSKEY is missing to continue validation:" " FAILED\n\n"); dns_name_free(&chase_signame, mctx); - if (chase_name.ndata != NULL) + if (dns_name_dynamic(&chase_name)) dns_name_free(&chase_name, mctx); return ISC_R_NOTFOUND; } @@ -4606,7 +4623,7 @@ getneededrr(dns_message_t *msg) printf("\n;; RRSIG for DNSKEY is missing to continue" " validation : FAILED\n\n"); dns_name_free(&chase_signame, mctx); - if (chase_name.ndata != NULL) + if (dns_name_dynamic(&chase_name)) dns_name_free(&chase_name, mctx); return ISC_R_NOTFOUND; } @@ -4697,6 +4714,7 @@ sigchase_bu(dns_message_t *msg) dns_name_t query_name; + dns_name_init(&query_name, NULL); nameFromString(current_lookup->textname, &query_name); result = prove_nx(msg, &query_name, current_lookup->rdclass, @@ -4792,7 +4810,6 @@ sigchase_bu(dns_message_t *msg) " the RRset\n"); INSIST(chase_sigdsrdataset != NULL); - dns_name_free(&chase_name, mctx); dup_name(&chase_signame, &chase_name, mctx); dns_name_free(&chase_signame, mctx); chase_rdataset = chase_dsrdataset; From 9105a6a730bfb8472c48230629c5a0aebb88c422 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 1 Jul 2004 00:22:29 +0000 Subject: [PATCH 06/14] 1682. [port] Update configure test for (long long) printf format. [RT #5066] --- CHANGES | 3 ++- configure | 41 +++++++++++++++++++++++++++-------------- configure.in | 31 ++++++++++++++++++++++--------- 3 files changed, 51 insertions(+), 24 deletions(-) diff --git a/CHANGES b/CHANGES index 43f11f7761..de8629b0ae 100644 --- a/CHANGES +++ b/CHANGES @@ -1,6 +1,7 @@ 1683. [bug] dig +sigchase could leak memory. [RT #11445] -1682. [placeholder] rt5066a +1682. [port] Update configure test for (long long) printf format. + [RT #5066] 1681. [bug] Only set SO_REUSEADDR when a port is specified in isc_socket_bind(). [RT #11742] diff --git a/configure b/configure index d8f6463c06..d05006f223 100755 --- a/configure +++ b/configure @@ -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.342 2004/06/18 01:37:34 marka Exp $ +# $Id: configure,v 1.343 2004/07/01 00:22:29 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.358 . +# From configure.in Revision: 1.359 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.59. # @@ -25659,12 +25659,15 @@ fi -# # Determine the printf format characters to use when printing -# values of type isc_int64_t. We make the assumption that platforms -# where a "long long" is the same size as a "long" (e.g., Alpha/OSF1) -# want "%ld" and everyone else can use "%lld". Win32 uses "%I64d", -# but that's defined elsewhere since we don't use configure on Win32. +# values of type isc_int64_t. This will normally be "ll", but where +# the compiler treats "long long" as a alias for "long" and printf +# doesn't know about "long long" use "l". Hopefully the sprintf +# will produce a inconsistant result in the later case. If the compiler +# fails due to seeing "%lld" we fall back to "l". +# +# Win32 uses "%I64d", but that's defined elsewhere since we don't use +# configure on Win32. # echo "$as_me:$LINENO: checking printf format modifier for 64-bit integers" >&5 echo $ECHO_N "checking printf format modifier for 64-bit integers... $ECHO_C" >&6 @@ -25679,7 +25682,17 @@ _ACEOF cat confdefs.h >>conftest.$ac_ext cat >>conftest.$ac_ext <<_ACEOF /* end confdefs.h. */ -main() { exit(!(sizeof(long long int) == sizeof(long int))); } + +#include +main() { + long long int j = 0; + char buf[100]; + buf[0] = 0; + sprintf(buf, "%lld", j); + exit((sizeof(long long int) != sizeof(long int))? 0 : + (strcmp(buf, "0") != 0)); +} + _ACEOF rm -f conftest$ac_exeext if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 @@ -25692,18 +25705,18 @@ if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 ac_status=$? echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); }; }; then - echo "$as_me:$LINENO: result: l" >&5 -echo "${ECHO_T}l" >&6 - ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"' + echo "$as_me:$LINENO: result: ll" >&5 +echo "${ECHO_T}ll" >&6 + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"' else echo "$as_me: program exited with status $ac_status" >&5 echo "$as_me: failed program was:" >&5 sed 's/^/| /' conftest.$ac_ext >&5 ( exit $ac_status ) -echo "$as_me:$LINENO: result: ll" >&5 -echo "${ECHO_T}ll" >&6 - ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"' +echo "$as_me:$LINENO: result: l" >&5 +echo "${ECHO_T}l" >&6 + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"' fi rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext conftest.$ac_ext fi diff --git a/configure.in b/configure.in index 42006b0d03..ce0744c7a6 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.358 $) +AC_REVISION($Revision: 1.359 $) AC_INIT(lib/dns/name.c) AC_PREREQ(2.13) @@ -1686,19 +1686,32 @@ AC_CHECK_FUNC(strerror, AC_DEFINE(HAVE_STRERROR)) AC_SUBST(ISC_EXTRA_OBJS) AC_SUBST(ISC_EXTRA_SRCS) -# # Determine the printf format characters to use when printing -# values of type isc_int64_t. We make the assumption that platforms -# where a "long long" is the same size as a "long" (e.g., Alpha/OSF1) -# want "%ld" and everyone else can use "%lld". Win32 uses "%I64d", -# but that's defined elsewhere since we don't use configure on Win32. +# values of type isc_int64_t. This will normally be "ll", but where +# the compiler treats "long long" as a alias for "long" and printf +# doesn't know about "long long" use "l". Hopefully the sprintf +# will produce a inconsistant result in the later case. If the compiler +# fails due to seeing "%lld" we fall back to "l". +# +# Win32 uses "%I64d", but that's defined elsewhere since we don't use +# configure on Win32. # AC_MSG_CHECKING(printf format modifier for 64-bit integers) -AC_TRY_RUN([main() { exit(!(sizeof(long long int) == sizeof(long int))); }], - [AC_MSG_RESULT(l) - ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'], +AC_TRY_RUN([ +#include +main() { + long long int j = 0; + char buf[100]; + buf[0] = 0; + sprintf(buf, "%lld", j); + exit((sizeof(long long int) != sizeof(long int))? 0 : + (strcmp(buf, "0") != 0)); +} +], [AC_MSG_RESULT(ll) ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'], + [AC_MSG_RESULT(l) + ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'], [AC_MSG_RESULT(assuming target platform uses ll) ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"']) AC_SUBST(ISC_PLATFORM_QUADFORMAT) From 0d8d36b7c8c55a3403cca6f9be9ab1b4675ffc73 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 1 Jul 2004 02:03:54 +0000 Subject: [PATCH 07/14] silence compiler --- bin/named/main.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/bin/named/main.c b/bin/named/main.c index ef0aa93979..8bf038da81 100644 --- a/bin/named/main.c +++ b/bin/named/main.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: main.c,v 1.137 2004/04/20 06:53:52 marka Exp $ */ +/* $Id: main.c,v 1.138 2004/07/01 02:03:54 marka Exp $ */ #include @@ -312,16 +312,18 @@ set_flags(const char *arg, struct flag_def *defs, unsigned int *ret) { for (;;) { const struct flag_def *def; const char *end = strchr(arg, ','); + int arglen; if (end == NULL) end = arg + strlen(arg); + arglen = end - arg; for (def = defs; def->name != NULL; def++) { - if (end - arg == (int)strlen(def->name) && - memcmp(arg, def->name, end - arg) == 0) { + if (arglen == (int)strlen(def->name) && + memcmp(arg, def->name, arglen) == 0) { *ret |= def->value; goto found; } } - ns_main_earlyfatal("unrecognized flag '%.*s'", end - arg, arg); + ns_main_earlyfatal("unrecognized flag '%.*s'", arglen, arg); found: if (*end == '\0') break; From 0a683f0dd30944da22da1e02d72458d9d00c99c2 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 1 Jul 2004 04:41:20 +0000 Subject: [PATCH 08/14] pullup: 1668. [port] solaris: allow applications compiling against libbind to be compiled with "cc -Xc". --- lib/bind/include/arpa/nameser_compat.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/bind/include/arpa/nameser_compat.h b/lib/bind/include/arpa/nameser_compat.h index 7f27225e87..d7aaf3f9cf 100644 --- a/lib/bind/include/arpa/nameser_compat.h +++ b/lib/bind/include/arpa/nameser_compat.h @@ -32,7 +32,7 @@ /* * from nameser.h 8.1 (Berkeley) 6/2/93 - * $Id: nameser_compat.h,v 1.5 2004/03/09 06:29:54 marka Exp $ + * $Id: nameser_compat.h,v 1.6 2004/07/01 04:41:20 marka Exp $ */ #ifndef _ARPA_NAMESER_COMPAT_ @@ -65,7 +65,7 @@ defined(__hppa) || defined(__hp9000) || \ defined(__hp9000s300) || defined(__hp9000s700) || \ defined(__hp3000s900) || defined(__hpux) || defined(MPE) || \ - defined (BIT_ZERO_ON_LEFT) || defined(m68k) || \ + defined (BIT_ZERO_ON_LEFT) || defined(m68k) || defined(__sparc) || \ (defined(__Lynx__) && \ (defined(__68k__) || defined(__sparc__) || defined(__powerpc__))) #define BYTE_ORDER BIG_ENDIAN From ae507663cfa05e0e218ecd88a867e79fa447feac Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 1 Jul 2004 04:53:14 +0000 Subject: [PATCH 09/14] indenting --- lib/isc/unix/socket.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/isc/unix/socket.c b/lib/isc/unix/socket.c index ad9f4e6bcb..572f5856ae 100644 --- a/lib/isc/unix/socket.c +++ b/lib/isc/unix/socket.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: socket.c,v 1.240 2004/06/30 23:35:16 marka Exp $ */ +/* $Id: socket.c,v 1.241 2004/07/01 04:53:14 marka Exp $ */ #include @@ -2864,7 +2864,7 @@ isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr) { */ if (isc_sockaddr_getport(sockaddr) != (in_port_t)0 && setsockopt(sock->fd, SOL_SOCKET, SO_REUSEADDR, (void *)&on, - sizeof(on)) < 0) { + sizeof(on)) < 0) { UNEXPECTED_ERROR(__FILE__, __LINE__, "setsockopt(%d) %s", sock->fd, isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL, From e9f33cdca0565d049941117d30e4c37ab3c5e990 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 2 Jul 2004 05:16:13 +0000 Subject: [PATCH 10/14] placeholder --- CHANGES | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGES b/CHANGES index de8629b0ae..c769d39159 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1684. [placeholder] rt10704 + 1683. [bug] dig +sigchase could leak memory. [RT #11445] 1682. [port] Update configure test for (long long) printf format. From fbdadf789f3057a5c90ebc026dbf2d174022bd28 Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Fri, 2 Jul 2004 21:37:58 +0000 Subject: [PATCH 11/14] 1684. [bug] Change #1679 loop tests weren't quite right. --- CHANGES | 2 ++ lib/dns/resolver.c | 6 +++--- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/CHANGES b/CHANGES index c769d39159..1cf8f4ce04 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ +1684. [bug] Change #1679 loop tests weren't quite right. + 1684. [placeholder] rt10704 1683. [bug] dig +sigchase could leak memory. [RT #11445] diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c index 0adba77421..107ac837da 100644 --- a/lib/dns/resolver.c +++ b/lib/dns/resolver.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.c,v 1.291 2004/06/27 01:21:41 marka Exp $ */ +/* $Id: resolver.c,v 1.292 2004/07/02 21:37:58 sra Exp $ */ #include @@ -2119,7 +2119,7 @@ fctx_nextaddress(fetchctx_t *fctx) { if (addrinfo != NULL) break; find = ISC_LIST_NEXT(find, publink); - if (find != fctx->find && find == NULL) + if (find == NULL) find = ISC_LIST_HEAD(fctx->finds); } while (find != start); } @@ -2164,7 +2164,7 @@ fctx_nextaddress(fetchctx_t *fctx) { if (addrinfo != NULL) break; find = ISC_LIST_NEXT(find, publink); - if (find != fctx->altfind && find == NULL) + if (find == NULL) find = ISC_LIST_HEAD(fctx->altfinds); } while (find != start); } From 351696ef9e44e31e200afc0b019f24af6b597471 Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Fri, 2 Jul 2004 21:39:56 +0000 Subject: [PATCH 12/14] wrong change number, sigh. --- CHANGES | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGES b/CHANGES index 1cf8f4ce04..9524ae36e7 100644 --- a/CHANGES +++ b/CHANGES @@ -1,4 +1,4 @@ -1684. [bug] Change #1679 loop tests weren't quite right. +1685. [bug] Change #1679 loop tests weren't quite right. 1684. [placeholder] rt10704 From 98f31157df406812d99ca5340baa89b3e35e0851 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 19 Jul 2004 05:54:08 +0000 Subject: [PATCH 13/14] pullup: 1669. [bug] Only test the gcc minor version when the major version is known. --- lib/bind/port/aix32/include/sys/cdefs.h | 4 ++-- lib/bind/port/aix4/include/sys/cdefs.h | 4 ++-- lib/bind/port/aux3/include/sys/cdefs.h | 2 +- lib/bind/port/cygwin/include/sys/cdefs.h | 4 ++-- lib/bind/port/hpux/include/sys/cdefs.h | 4 ++-- lib/bind/port/hpux10/include/sys/cdefs.h | 4 ++-- lib/bind/port/hpux9/include/sys/cdefs.h | 4 ++-- lib/bind/port/irix/include/sys/cdefs.h | 4 ++-- lib/bind/port/lynxos/include/sys/cdefs.h | 4 ++-- lib/bind/port/mpe/include/sys/cdefs.h | 4 ++-- lib/bind/port/next/include/sys/cdefs.h | 4 ++-- lib/bind/port/qnx/include/sys/cdefs.h | 3 +-- lib/bind/port/sco42/include/sys/cdefs.h | 4 ++-- lib/bind/port/solaris/include/sys/cdefs.h | 4 ++-- lib/bind/port/sunos/include/sys/cdefs.h | 4 ++-- lib/bind/port/unixware20/include/sys/cdefs.h | 4 ++-- lib/bind/port/unixware212/include/sys/cdefs.h | 4 ++-- 17 files changed, 32 insertions(+), 33 deletions(-) diff --git a/lib/bind/port/aix32/include/sys/cdefs.h b/lib/bind/port/aix32/include/sys/cdefs.h index 0c7c9906c7..9fdc4d6ddb 100644 --- a/lib/bind/port/aix32/include/sys/cdefs.h +++ b/lib/bind/port/aix32/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/04/11 01:30:12 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:53:58 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/aix4/include/sys/cdefs.h b/lib/bind/port/aix4/include/sys/cdefs.h index 61fe4dcd14..3b2d0a2e84 100644 --- a/lib/bind/port/aix4/include/sys/cdefs.h +++ b/lib/bind/port/aix4/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/10 04:23:15 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:53:59 marka Exp $ */ #ifndef _CDEFS_H_ @@ -130,7 +130,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/aux3/include/sys/cdefs.h b/lib/bind/port/aux3/include/sys/cdefs.h index 965883cee7..7c9d241275 100644 --- a/lib/bind/port/aux3/include/sys/cdefs.h +++ b/lib/bind/port/aux3/include/sys/cdefs.h @@ -114,7 +114,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/cygwin/include/sys/cdefs.h b/lib/bind/port/cygwin/include/sys/cdefs.h index a2c123b883..d0d39937e9 100644 --- a/lib/bind/port/cygwin/include/sys/cdefs.h +++ b/lib/bind/port/cygwin/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2002/12/27 03:13:51 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:01 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/hpux/include/sys/cdefs.h b/lib/bind/port/hpux/include/sys/cdefs.h index aca6f0a241..2cc58f079c 100644 --- a/lib/bind/port/hpux/include/sys/cdefs.h +++ b/lib/bind/port/hpux/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/04/09 09:17:16 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:02 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/hpux10/include/sys/cdefs.h b/lib/bind/port/hpux10/include/sys/cdefs.h index 868f9bfaf8..2cc58f079c 100644 --- a/lib/bind/port/hpux10/include/sys/cdefs.h +++ b/lib/bind/port/hpux10/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/17 06:25:49 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:02 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/hpux9/include/sys/cdefs.h b/lib/bind/port/hpux9/include/sys/cdefs.h index d298c13c18..8aed23d531 100644 --- a/lib/bind/port/hpux9/include/sys/cdefs.h +++ b/lib/bind/port/hpux9/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/17 06:25:50 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:03 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/irix/include/sys/cdefs.h b/lib/bind/port/irix/include/sys/cdefs.h index d298c13c18..8aed23d531 100644 --- a/lib/bind/port/irix/include/sys/cdefs.h +++ b/lib/bind/port/irix/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/17 06:25:50 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:03 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/lynxos/include/sys/cdefs.h b/lib/bind/port/lynxos/include/sys/cdefs.h index 213e34e189..e0fd941bff 100644 --- a/lib/bind/port/lynxos/include/sys/cdefs.h +++ b/lib/bind/port/lynxos/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/17 06:25:51 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:04 marka Exp $ */ #ifndef _CDEFS_H_ @@ -129,7 +129,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/mpe/include/sys/cdefs.h b/lib/bind/port/mpe/include/sys/cdefs.h index 5c6264389b..b83e9a34cf 100644 --- a/lib/bind/port/mpe/include/sys/cdefs.h +++ b/lib/bind/port/mpe/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/17 06:25:51 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:04 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/next/include/sys/cdefs.h b/lib/bind/port/next/include/sys/cdefs.h index 8f5d38ef59..0bf52d2d89 100644 --- a/lib/bind/port/next/include/sys/cdefs.h +++ b/lib/bind/port/next/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/17 06:25:55 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:05 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/qnx/include/sys/cdefs.h b/lib/bind/port/qnx/include/sys/cdefs.h index f814b0c0bc..2b3f9ec5be 100644 --- a/lib/bind/port/qnx/include/sys/cdefs.h +++ b/lib/bind/port/qnx/include/sys/cdefs.h @@ -108,8 +108,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || \ - (__GNUC__ == 2 && __GNUC_MINOR__ < 5) +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/sco42/include/sys/cdefs.h b/lib/bind/port/sco42/include/sys/cdefs.h index 274057c675..6c57c8a0ed 100644 --- a/lib/bind/port/sco42/include/sys/cdefs.h +++ b/lib/bind/port/sco42/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/17 06:25:57 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:06 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/solaris/include/sys/cdefs.h b/lib/bind/port/solaris/include/sys/cdefs.h index 66950406d1..67aac00cc7 100644 --- a/lib/bind/port/solaris/include/sys/cdefs.h +++ b/lib/bind/port/solaris/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/04/02 06:29:20 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:07 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/sunos/include/sys/cdefs.h b/lib/bind/port/sunos/include/sys/cdefs.h index ce95a0e005..67aac00cc7 100644 --- a/lib/bind/port/sunos/include/sys/cdefs.h +++ b/lib/bind/port/sunos/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/17 06:25:58 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:07 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/unixware20/include/sys/cdefs.h b/lib/bind/port/unixware20/include/sys/cdefs.h index 8b662a1cf1..67aac00cc7 100644 --- a/lib/bind/port/unixware20/include/sys/cdefs.h +++ b/lib/bind/port/unixware20/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/17 06:26:00 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:07 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile diff --git a/lib/bind/port/unixware212/include/sys/cdefs.h b/lib/bind/port/unixware212/include/sys/cdefs.h index fa97a4f24d..7752c58ffd 100644 --- a/lib/bind/port/unixware212/include/sys/cdefs.h +++ b/lib/bind/port/unixware212/include/sys/cdefs.h @@ -55,7 +55,7 @@ /* * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 - * $Id: cdefs.h,v 1.1 2001/05/17 06:26:01 marka Exp $ + * $Id: cdefs.h,v 1.2 2004/07/19 05:54:08 marka Exp $ */ #ifndef _CDEFS_H_ @@ -127,7 +127,7 @@ * these work for GNU C++ (modulo a slight glitch in the C++ grammar * in the distribution version of 2.5.5). */ -#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#if !defined(__GNUC__) || __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) #define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) #define __dead __volatile From 5f238416b00d92bbc146793f840da5018c15271f Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 20 Jul 2004 02:51:25 +0000 Subject: [PATCH 14/14] new draft --- ... => draft-ietf-dnsext-dnssec-intro-11.txt} | 2970 ++++---- ... draft-ietf-dnsext-dnssec-protocol-07.txt} | 6442 ++++++++--------- ...> draft-ietf-dnsext-dnssec-records-09.txt} | 3810 +++++----- ...t-ietf-dnsop-ipv6-dns-configuration-02.txt | 1321 ++++ .../draft-ietf-dnsop-ipv6-dns-issues-04.txt | 1233 ---- .../draft-ietf-dnsop-ipv6-dns-issues-08.txt | 1960 +++++ 6 files changed, 9780 insertions(+), 7956 deletions(-) rename doc/draft/{draft-ietf-dnsext-dnssec-intro-10.txt => draft-ietf-dnsext-dnssec-intro-11.txt} (78%) rename doc/draft/{draft-ietf-dnsext-dnssec-protocol-06.txt => draft-ietf-dnsext-dnssec-protocol-07.txt} (81%) rename doc/draft/{draft-ietf-dnsext-dnssec-records-08.txt => draft-ietf-dnsext-dnssec-records-09.txt} (74%) create mode 100644 doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt delete mode 100644 doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt create mode 100644 doc/draft/draft-ietf-dnsop-ipv6-dns-issues-08.txt diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt similarity index 78% rename from doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt rename to doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt index 5ac9cba56e..0783e7b26e 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt @@ -1,1513 +1,1457 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: November 15, 2004 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - May 17, 2004 - - - DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-10 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 15, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - The Domain Name System Security Extensions (DNSSEC) add data origin - authentication and data integrity to the Domain Name System. This - document introduces these extensions, and describes their - capabilities and limitations. This document also discusses the - services that the DNS security extensions do and do not provide. - - - -Arends, et al. Expires November 15, 2004 [Page 1] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - - Last, this document describes the interrelationships between the - group of documents that collectively describe DNSSEC. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 - 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 - 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 - 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9 - 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 - 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 - 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 - 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 - 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 - 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 - 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 - 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 - 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 - 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 - Intellectual Property and Copyright Statements . . . . . . . . 26 - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 2] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -1. Introduction - - This document introduces the Domain Name System Security Extensions - (DNSSEC). This document and its two companion documents - ([I-D.ietf-dnsext-dnssec-records] and - [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the - security extensions defined in RFC 2535 [RFC2535] and its - predecessors. These security extensions consist of a set of new - resource record types and modifications to the existing DNS protocol - [RFC1035]. The new records and protocol modifications are not fully - described in this document, but are described in a family of - documents outlined in Section 10. Section 3 and Section 4 describe - the capabilities and limitations of the security extensions in - greater detail. Section 5 discusses the scope of the document set. - Section 6, Section 7, Section 8, and Section 9 discuss the effect - that these security extensions will have on resolvers, stub - resolvers, zones and name servers. - - This document and its two companions update and obsolete RFCs 2535 - [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 - [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress - [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but - does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 - [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts - of 3226 [RFC3226] (dealing with DNSSEC). - - The DNS security extensions provide origin authentication and - integrity protection for DNS data, as well as a means of public key - distribution. These extensions do not provide confidentiality. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 3] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -2. Definitions of Important DNSSEC Terms - - This section defines a number of terms used in this document set. - Since this is intended to be useful as a reference while reading the - rest of the document set, first-time readers may wish to skim this - section quickly, read the rest of this document, then come back to - this section. - - Authentication Chain: An alternating sequence of DNSKEY RRsets and DS - RRsets forms a chain of signed data, with each link in the chain - vouching for the next. A DNSKEY RR is used to verify the - signature covering a DS RR and allows the DS RR to be - authenticated. The DS RR contains a hash of another DNSKEY RR and - this new DNSKEY RR is authenticated by matching the hash in the DS - RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset - and, in turn, some DNSKEY RR in this set may be used to - authenticate another DS RR and so forth until the chain finally - ends with a DNSKEY RR whose corresponding private key signs the - desired DNS data. For example, the root DNSKEY RRset can be used - to authenticate the DS RRset for "example." The "example." DS - RRset contains a hash that matches some "example." DNSKEY, and - this DNSKEY's corresponding private key signs the "example." - DNSKEY RRset. Private key counterparts of the "example." DNSKEY - RRset sign data records such as "www.example." as well as DS RRs - for delegations such as "subzone.example." - - Authentication Key: A public key that a security-aware resolver has - verified and can therefore use to authenticate data. A - security-aware resolver can obtain authentication keys in three - ways. First, the resolver is generally configured to know about - at least one public key; this configured data is usually either - the public key itself or a hash of the public key as found in the - DS RR (see "trust anchor"). Second, the resolver may use an - authenticated public key to verify a DS RR and its associated - DNSKEY RR. Third, the resolver may be able to determine that a - new public key has been signed by the private key corresponding to - another public key which the resolver has verified. Note that the - resolver must always be guided by local policy when deciding - whether to authenticate a new public key, even if the local policy - is simply to authenticate any new public key for which the - resolver is able verify the signature. - - Delegation Point: Term used to describe the name at the parental side - of a zone cut. That is, the delegation point for "foo.example" - would be the foo.example node in the "example" zone (as opposed to - the zone apex of the "foo.example" zone). - - - - - -Arends, et al. Expires November 15, 2004 [Page 4] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - - Island of Security: Term used to describe a signed, delegated zone - that does not have an authentication chain from its delegating - parent. That is, there is no DS RR containing a hash of a DNSKEY - RR for the island in its delegating parent zone (see - [I-D.ietf-dnsext-dnssec-records]). An island of security is served - by security-aware name servers and may provide authentication - chains to any delegated child zones. Responses from an island of - security or its descendents can only be authenticated if its - authentication keys can be authenticated by some trusted means out - of band from the DNS protocol. - - Key Signing Key: An authentication key that corresponds to a private - key used to sign one or more other authentication keys for a given - zone. Typically, the private key corresponding to a key signing - key will sign a zone signing key, which in turn has a - corresponding private key which will sign other zone data. Local - policy may require the zone signing key to be changed frequently, - while the key signing key may have a longer validity period in - order to provide a more stable secure entry point into the zone. - Designating an authentication key as a key signing key is purely - an operational issue: DNSSEC validation does not distinguish - between key signing keys and other DNSSEC authentication keys, and - it is possible to use a single key as both a key signing key and a - zone signing key. Key signing keys are discussed in more detail - in [RFC3757]. Also see: zone signing key. - - Non-Validating Security-Aware Stub Resolver: A security-aware stub - resolver which trusts one or more security-aware recursive name - servers to perform most of the tasks discussed in this document - set on its behalf. In particular, a non-validating security-aware - stub resolver is an entity which sends DNS queries, receives DNS - responses, and is capable of establishing an appropriately secured - channel to a security-aware recursive name server which will - provide these services on behalf of the security-aware stub - resolver. See also: security-aware stub resolver, validating - security-aware stub resolver. - - Non-Validating Stub Resolver: A less tedious term for a - non-validating security-aware stub resolver. - - Security-Aware Name Server: An entity acting in the role of a name - server (defined in section 2.4 of [RFC1034]) that understands the - DNS security extensions defined in this document set. In - particular, a security-aware name server is an entity which - receives DNS queries, sends DNS responses, supports the EDNS0 - [RFC2671] message size extension and the DO bit [RFC3225], and - supports the RR types and message header bits defined in this - document set. - - - -Arends, et al. Expires November 15, 2004 [Page 5] - - - Security-Aware Recursive Name Server: An entity which acts in both - the security-aware name server and security-aware resolver roles. - A more cumbersome equivalent phrase would be "a security-aware - name server which offers recursive service". - - Security-Aware Resolver: An entity acting in the role of a resolver - (defined in section 2.4 of [RFC1034]) which understands the DNS - security extensions defined in this document set. In particular, - a security-aware resolver is an entity which sends DNS queries, - receives DNS responses, supports the EDNS0 [RFC2671] message size - extension and the DO bit [RFC3225], and is capable of using the RR - types and message header bits defined in this document set to - provide DNSSEC services. - - Security-Aware Stub Resolver: An entity acting in the role of a stub - resolver (defined in section 5.3.1 of [RFC1034]) which has enough - of an understanding the DNS security extensions defined in this - document set to provide additional services not available from a - security-oblivious stub resolver. Security-aware stub resolvers - may be either "validating" or "non-validating" depending on - whether the stub resolver attempts to verify DNSSEC signatures on - its own or trusts a friendly security-aware name server to do so. - See also: validating stub resolver, non-validating stub resolver. - - Security-Oblivious : An that is not - "security-aware". - - Signed Zone: A zone whose RRsets are signed and which contains - properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS - records. - - Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A - validating security-aware resolver uses this public key or hash as - a starting point for building the authentication chain to a signed - DNS response. In general, a validating resolver will need to - obtain the initial values of its trust anchors via some secure or - trusted means outside the DNS protocol. Presence of a trust - anchor also implies that the resolver should expect the zone to - which the trust anchor points to be signed - - Unsigned Zone: A zone that is not signed. - - Validating Security-Aware Stub Resolver: A security-aware resolver - that sends queries in recursive mode but which performs signature - validation on its own rather than just blindly trusting an - upstream security-aware recursive name server. See also: - security-aware stub resolver, non-validating security-aware stub - resolver. - - - - - -Arends, et al. Expires November 15, 2004 [Page 6] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - - Validating Stub Resolver: A less tedious term for a validating - security-aware stub resolver. - - Zone Signing Key: An authentication key that corresponds to a private - key used to sign a zone. Typically a zone signing key will be - part of the same DNSKEY RRset as the key signing key whose - corresponding private key signs this DNSKEY RRset, but the zone - signing key is used for a slightly different purpose, and may - differ from the key signing key in other ways, such as validity - lifetime. Designating an authentication key as a zone signing key - is purely an operational issue: DNSSEC validation does not - distinguish between zone signing keys and other DNSSEC - authentication keys, and it is possible to use a single key as - both a key signing key and a zone signing key. See also: key - signing key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 7] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -3. Services Provided by DNS Security - - The Domain Name System (DNS) security extensions provide origin - authentication and integrity assurance services for DNS data, - including mechanisms for authenticated denial of existence of DNS - data. These mechanisms are described below. - - These mechanisms require changes to the DNS protocol. DNSSEC adds - four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two - new message header bits (CD and AD). In order to support the larger - DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also - requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support - for the DO bit [RFC3225], so that a security-aware resolver can - indicate in its queries that it wishes to receive DNSSEC RRs in - response messages. - - These services protect against most of the threats to the Domain Name - System described in [I-D.ietf-dnsext-dns-threats]. - -3.1 Data Origin Authentication and Data Integrity - - DNSSEC provides authentication by associating cryptographically - generated digital signatures with DNS RRsets. These digital - signatures are stored in a new resource record, the RRSIG record. - Typically, there will be a single private key that signs a zone's - data, but multiple keys are possible: for example, there may be keys - for each of several different digital signature algorithms. If a - security-aware resolver reliably learns a zone's public key, it can - authenticate that zone's signed data. An important DNSSEC concept is - that the key that signs a zone's data is associated with the zone - itself and not with the zone's authoritative name servers (public - keys for DNS transaction authentication mechanisms may also appear in - zones, as described in [RFC2931], but DNSSEC itself is concerned with - object security of DNS data, not channel security of DNS - transactions). - - A security-aware resolver can learn a zone's public key either by - having a trust anchor configured into the resolver or by normal DNS - resolution. To allow the latter, public keys are stored in a new - type of resource record, the DNSKEY RR. Note that the private keys - used to sign zone data must be kept secure, and should be stored - offline when practical to do so. To discover a public key reliably - via DNS resolution, the target key itself needs to be signed by - either a configured authentication key or another key that has been - authenticated previously. Security-aware resolvers authenticate zone - information by forming an authentication chain from a newly learned - public key back to a previously known authentication public key, - which in turn either has been configured into the resolver or must - - - -Arends, et al. Expires November 15, 2004 [Page 8] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - - have been learned and verified previously. Therefore, the resolver - must be configured with at least one trust anchor. If the configured - key is a zone signing key, then it will authenticate the associated - zone; if the configured key is a key signing key, it will - authenticate a zone signing key. If the resolver has been configured - with the hash of a key rather than the key itself, the resolver may - need to obtain the key via a DNS query. To help security-aware - resolvers establish this authentication chain, security-aware name - servers attempt to send the signature(s) needed to authenticate a - zone's public key(s) in the DNS reply message along with the public - key itself, provided there is space available in the message. - - The Delegation Signer (DS) RR type simplifies some of the - administrative tasks involved in signing delegations across - organizational boundaries. The DS RRset resides at a delegation - point in a parent zone and indicates the public key(s) corresponding - to the private key(s) used to self-sign the DNSKEY RRset at the - delegated child zone's apex. The administrator of the child zone, in - turn, uses the private key(s) corresponding to one or more of the - public keys in this DNSKEY RRset to sign the child zone's data. The - typical authentication chain is therefore - DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more - DS->DNSKEY subchains. DNSSEC permits more complex authentication - chains, such as additional layers of DNSKEY RRs signing other DNSKEY - RRs within a zone. - - A security-aware resolver normally constructs this authentication - chain from the root of the DNS hierarchy down to the leaf zones based - on configured knowledge of the public key for the root. Local - policy, however, may also allow a security-aware resolver to use one - or more configured public keys (or hashes of public keys) other than - the root public key, or may not provide configured knowledge of the - root public key, or may prevent the resolver from using particular - public keys for arbitrary reasons even if those public keys are - properly signed with verifiable signatures. DNSSEC provides - mechanisms by which a security-aware resolver can determine whether - an RRset's signature is "valid" within the meaning of DNSSEC. In the - final analysis however, authenticating both DNS keys and data is a - matter of local policy, which may extend or even override the - protocol extensions defined in this document set. See for further - discussion. - -3.2 Authenticating Name and Type Non-Existence - - The security mechanism described in Section 3.1 only provides a way - to sign existing RRsets in a zone. The problem of providing negative - responses with the same level of authentication and integrity - requires the use of another new resource record type, the NSEC - - - -Arends, et al. Expires November 15, 2004 [Page 9] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - - record. The NSEC record allows a security-aware resolver to - authenticate a negative reply for either name or type non-existence - via the same mechanisms used to authenticate other DNS replies. Use - of NSEC records requires a canonical representation and ordering for - domain names in zones. Chains of NSEC records explicitly describe - the gaps, or "empty space", between domain names in a zone, as well - as listing the types of RRsets present at existing names. Each NSEC - record is signed and authenticated using the mechanisms described in - Section 3.1. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 10] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -4. Services Not Provided by DNS Security - - DNS was originally designed with the assumptions that the DNS will - return the same answer to any given query regardless of who may have - issued the query, and that all data in the DNS is thus visible. - Accordingly, DNSSEC is not designed to provide confidentiality, - access control lists, or other means of differentiating between - inquirers. - - DNSSEC provides no protection against denial of service attacks. - Security-aware resolvers and security-aware name servers are - vulnerable to an additional class of denial of service attacks based - on cryptographic operations. Please see Section 12 for details. - - The DNS security extensions provide data and origin authentication - for DNS data. The mechanisms outlined above are not designed to - protect operations such as zone transfers and dynamic update - [RFC3007]. Message authentication schemes described in [RFC2845] and - [RFC2931] address security operations that pertain to these - transactions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 11] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -5. Scope of the DNSSEC Document Set and Last Hop Issues - - The specification in this document set defines the behavior for zone - signers and security-aware name servers and resolvers in such a way - that the validating entities can unambiguously determine the state of - the data. - - A validating resolver can determine these 4 states: - - Secure: The validating resolver has a trust anchor, a chain of trust - and is able to verify all the signatures in the response. - - Insecure: The validating resolver has a trust anchor, a chain of - trust, and, at some delegation point, signed proof of the - non-existence of a DS record. That indicates that subsequent - branches in the tree are provably insecure. A validating resolver - may have local policy to mark parts of the domain space as - insecure. - - Bogus: The validating resolver has a trust anchor and there is a - secure delegation which is indicating that subsidiary data will be - signed, but the response fails to validate due to one or more - reasons: missing signatures, expired signatures, signatures with - unsupported algorithms, data missing which the relevant NSEC RR - says should be present, and so forth. - - Indeterminate: There is no trust anchor which would indicate that a - specific portion of the tree is secure. This is the default - operation mode. - - This specification only defines how security aware name servers can - signal non-validating stub resolvers that data was found to be bogus - (using RCODE=2, "Server Failure" -- see - [I-D.ietf-dnsext-dnssec-protocol]). - - There is a mechanism for security aware name servers to signal - security-aware stub resolvers that data was found to be secure (using - the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). - - This specification does not define a format for communicating why - responses were found to be bogus or marked as insecure. The current - signaling mechanism does not distinguish between indeterminate and - insecure. - - A method for signaling advanced error codes and policy between a - security aware stub resolver and security aware recursive nameservers - is a topic for future work, as is the interface between a security - aware resolver and the applications that use it. Note, however, that - - - -Arends, et al. Expires November 15, 2004 [Page 12] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - - the lack of the specification of such communication does not prohibit - deployment of signed zones or the deployment of security aware - recursive name servers that prohibit propagation of bogus data to the - applications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 13] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -6. Resolver Considerations - - A security-aware resolver needs to be able to perform cryptographic - functions necessary to verify digital signatures using at least the - mandatory-to-implement algorithm(s). Security-aware resolvers must - also be capable of forming an authentication chain from a newly - learned zone back to an authentication key, as described above. This - process might require additional queries to intermediate DNS zones to - obtain necessary DNSKEY, DS and RRSIG records. A security-aware - resolver should be configured with at least one trust anchor as the - starting point from which it will attempt to establish authentication - chains. - - If a security-aware resolver is separated from the relevant - authoritative name servers by a recursive name server or by any sort - of device which acts as a proxy for DNS, and if the recursive name - server or proxy is not security-aware, the security-aware resolver - may not be capable of operating in a secure mode. For example, if a - security-aware resolver's packets are routed through a network - address translation device that includes a DNS proxy which is not - security-aware, the security-aware resolver may find it difficult or - impossible to obtain or validate signed DNS data. - - If a security-aware resolver must rely on an unsigned zone or a name - server that is not security aware, the resolver may not be able to - validate DNS responses, and will need a local policy on whether to - accept unverified responses. - - A security-aware resolver should take a signature's validation period - into consideration when determining the TTL of data in its cache, to - avoid caching signed data beyond the validity period of the - signature, but should also allow for the possibility that the - security-aware resolver's own clock is wrong. Thus, a security-aware - resolver which is part of a security-aware recursive name server will - need to pay careful attention to the DNSSEC "checking disabled" (CD) - bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid - blocking valid signatures from getting through to other - security-aware resolvers which are clients of this recursive name - server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure - recursive server handles queries with the CD bit set. - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 14] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -7. Stub Resolver Considerations - - Although not strictly required to do so by the protocol, most DNS - queries originate from stub resolvers. Stub resolvers, by - definition, are minimal DNS resolvers which use recursive query mode - to offload most of the work of DNS resolution to a recursive name - server. Given the widespread use of stub resolvers, the DNSSEC - architecture has to take stub resolvers into account, but the - security features needed in a stub resolver differ in some respects - from those needed in a full security-aware resolver. - - Even a security-oblivious stub resolver may get some benefit from - DNSSEC if the recursive name servers it uses are security-aware, but - for the stub resolver to place any real reliance on DNSSEC services, - the stub resolver must trust both the recursive name servers in - question and the communication channels between itself and those name - servers. The first of these issues is a local policy issue: in - essence, a security-oblivious stub resolver has no real choice but to - place itself at the mercy of the recursive name servers that it uses, - since it does not perform DNSSEC validity checks on its own. The - second issue requires some kind of channel security mechanism; proper - use of DNS transaction authentication mechanisms such as SIG(0) or - TSIG would suffice, as would appropriate use of IPsec, and particular - implementations may have other choices available, such as operating - system specific interprocess communication mechanisms. - Confidentiality is not needed for this channel, but data integrity - and message authentication are. - - A security-aware stub resolver that does trust both its recursive - name servers and its communication channel to them may choose to - examine the setting of the AD bit in the message header of the - response messages it receives. The stub resolver can use this flag - bit as a hint to find out whether the recursive name server was able - to validate signatures for all of the data in the Answer and - Authority sections of the response. - - There is one more step that a security-aware stub resolver can take - if, for whatever reason, it is not able to establish a useful trust - relationship with the recursive name servers which it uses: it can - perform its own signature validation, by setting the Checking - Disabled (CD) bit in its query messages. A validating stub resolver - is thus able to treat the DNSSEC signatures as a trust relationship - between the zone administrator and the stub resolver itself. - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 15] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -8. Zone Considerations - - There are several differences between signed and unsigned zones. A - signed zone will contain additional security-related records (RRSIG, - DNSKEY, DS and NSEC records). RRSIG and NSEC records may be - generated by a signing process prior to serving the zone. The RRSIG - records that accompany zone data have defined inception and - expiration times, which establish a validity period for the - signatures and the zone data the signatures cover. - -8.1 TTL values vs. RRSIG validity period - - It is important to note the distinction between a RRset's TTL value - and the signature validity period specified by the RRSIG RR covering - that RRset. DNSSEC does not change the definition or function of the - TTL value, which is intended to maintain database coherency in - caches. A caching resolver purges RRsets from its cache no later than - the end of the time period specified by the TTL fields of those - RRsets, regardless of whether or not the resolver is security-aware. - - The inception and expiration fields in the RRSIG RR - [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time - period during which the signature can be used to validate the covered - RRset. The signatures associated with signed zone data are only - valid for the time period specified by these fields in the RRSIG RRs - in question. TTL values cannot extend the validity period of signed - RRsets in a resolver's cache, but the resolver may use the time - remaining before expiration of the signature validity period of a - signed RRset as an upper bound for the TTL of the signed RRset and - its associated RRSIG RR in the resolver's cache. - -8.2 New Temporal Dependency Issues for Zones - - Information in a signed zone has a temporal dependency which did not - exist in the original DNS protocol. A signed zone requires regular - maintenance to ensure that each RRset in the zone has a current valid - RRSIG RR. The signature validity period of an RRSIG RR is an - interval during which the signature for one particular signed RRset - can be considered valid, and the signatures of different RRsets in a - zone may expire at different times. Re-signing one or more RRsets in - a zone will change one or more RRSIG RRs, which in turn will require - incrementing the zone's SOA serial number to indicate that a zone - change has occurred and re-signing the SOA RRset itself. Thus, - re-signing any RRset in a zone may also trigger DNS NOTIFY messages - and zone transfers operations. - - - - - - -Arends, et al. Expires November 15, 2004 [Page 16] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -9. Name Server Considerations - - A security-aware name server should include the appropriate DNSSEC - records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from - resolvers which have signaled their willingness to receive such - records via use of the DO bit in the EDNS header, subject to message - size limitations. Since inclusion of these DNSSEC RRs could easily - cause UDP message truncation and fallback to TCP, a security-aware - name server must also support the EDNS "sender's UDP payload" - mechanism. - - If possible, the private half of each DNSSEC key pair should be kept - offline, but this will not be possible for a zone for which DNS - dynamic update has been enabled. In the dynamic update case, the - primary master server for the zone will have to re-sign the zone when - updated, so the private key corresponding to the zone signing key - will have to be kept online. This is an example of a situation where - the ability to separate the zone's DNSKEY RRset into zone signing - key(s) and key signing key(s) may be useful, since the key signing - key(s) in such a case can still be kept offline and may have a longer - useful lifetime than the zone signing key(s). - - DNSSEC, by itself, is not enough to protect the integrity of an - entire zone during zone transfer operations, since even a signed zone - contains some unsigned, nonauthoritative data if the zone has any - children. Therefore, zone maintenance operations will require some - additional mechanisms (most likely some form of channel security, - such as TSIG, SIG(0), or IPsec). - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 17] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -10. DNS Security Document Family - - The DNSSEC document set can be partitioned into several main groups, - under the larger umbrella of the DNS base protocol documents. - - The "DNSSEC protocol document set" refers to the three documents - which form the core of the DNS security extensions: - 1. DNS Security Introduction and Requirements (this document) - 2. Resource Records for DNS Security Extensions - [I-D.ietf-dnsext-dnssec-records] - 3. Protocol Modifications for the DNS Security Extensions - [I-D.ietf-dnsext-dnssec-protocol] - - Additionally, any document that would add to, or change the core DNS - Security extensions would fall into this category. This includes any - future work on the communication between security-aware stub - resolvers and upstream security-aware recursive name servers. - - The "Digital Signature Algorithm Specification" document set refers - to the group of documents that describe how specific digital - signature algorithms should be implemented to fit the DNSSEC resource - record format. Each document in this set deals with a specific - digital signature algorithm. - - The "Transaction Authentication Protocol" document set refers to the - group of documents that deal with DNS message authentication, - including secret key establishment and verification. While not - strictly part of the DNSSEC specification as defined in this set of - documents, this group is noted because of its relationship to DNSSEC. - - The final document set, "New Security Uses", refers to documents that - seek to use proposed DNS Security extensions for other security - related purposes. DNSSEC does not provide any direct security for - these new uses, but may be used to support them. Documents that fall - in this category include the use of DNS in the storage and - distribution of certificates [RFC2538]. - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 18] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -11. IANA Considerations - - This overview document introduces no new IANA considerations. Please - see [I-D.ietf-dnsext-dnssec-records] for a complete review of the - IANA considerations introduced by DNSSEC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 19] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -12. Security Considerations - - This document introduces the DNS security extensions and describes - the document set that contains the new security records and DNS - protocol modifications. The extensions provide data origin - authentication and data integrity using digital signatures over - resource record sets.This document discusses the capabilities and - limitations of these extensions. - - In order for a security-aware resolver to validate a DNS response, - all zones along the path from the trusted starting point to the zone - containing the response zones must be signed, and all name servers - and resolvers involved in the resolution process must be - security-aware, as defined in this document set. A security-aware - resolver cannot verify responses originating from an unsigned zone, - from a zone not served by a security-aware name server, or for any - DNS data which the resolver is only able to obtain through a - recursive name server which is not security-aware. If there is a - break in the authentication chain such that a security-aware resolver - cannot obtain and validate the authentication keys it needs, then the - security-aware resolver cannot validate the affected DNS data. - - This document briefly discusses other methods of adding security to a - DNS query, such as using a channel secured by IPsec or using a DNS - transaction authentication mechanism, but transaction security is not - part of DNSSEC per se. - - A non-validating security-aware stub resolver, by definition, does - not perform DNSSEC signature validation on its own, and thus is - vulnerable both to attacks on (and by) the security-aware recursive - name servers which perform these checks on its behalf and also to - attacks on its communication with those security-aware recursive name - servers. Non-validating security-aware stub resolvers should use some - form of channel security to defend against the latter threat. The - only known defense against the former threat would be for the - security-aware stub resolver to perform its own signature validation, - at which point, again by definition, it would no longer be a - non-validating security-aware stub resolver. - - DNSSEC does not protect against denial of service attacks. DNSSEC - makes DNS vulnerable to a new class of denial of service attacks - based on cryptographic operations against security-aware resolvers - and security-aware name servers, since an attacker can attempt to use - DNSSEC mechanisms to consume a victim's resources. This class of - attacks takes at least two forms. An attacker may be able to consume - resources in a security-aware resolver's signature validation code by - tampering with RRSIG RRs in response messages or by constructing - needlessly complex signature chains. An attacker may also be able to - - - -Arends, et al. Expires November 15, 2004 [Page 20] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - - consume resources in a security-aware name server which supports DNS - dynamic update, by sending a stream of update messages that force the - security-aware name server to re-sign some RRsets in the zone more - frequently than would otherwise be necessary. - - DNSSEC introduces the ability for a hostile party to enumerate all - the names in a zone by following the NSEC chain. NSEC RRs assert - which names do not exist in a zone by linking from existing name to - existing name along a canonical ordering of all the names within a - zone. Thus, an attacker can query these NSEC RRs in sequence to - obtain all the names in a zone. While not an attack on the DNS - itself, this could allow an attacker to map network hosts or other - resources by enumerating the contents of a zone. There are non-DNS - protocol means of detecting and limiting this attack beyond the scope - of this document set. - - DNSSEC introduces significant additional complexity to the DNS, and - thus introduces many new opportunities for implementation bugs and - misconfigured zones. In particular, enabling DNSSEC signature - validation in a resolver may cause entire legitimate zones to become - effectively unreachable due to DNSSEC configuration errors or bugs. - - DNSSEC does not provide confidentiality, due to a deliberate design - choice. - - DNSSEC does not protect against tampering with unsigned zone data. - Non-authoritative data at zone cuts (glue and NS RRs in the parent - zone) are not signed. This does not pose a problem when validating - the authentication chain, but does mean that the non-authoritative - data itself is vulnerable to tampering during zone transfer - operations. Thus, while DNSSEC can provide data origin - authentication and data integrity for RRsets, it cannot do so for - zones, and other mechanisms must be used to protect zone transfer - operations. - - Please see [I-D.ietf-dnsext-dnssec-records] and - [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations. - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 21] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -13. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group. While explicitly listing everyone - who has contributed during the decade during which DNSSEC has been - under development would be an impossible task, the editors would - particularly like to thank the following people for their - contributions to and comments on this document set: Mark Andrews, - Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, - Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael - Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip - Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf - Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted - Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson, - Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik - Rozendaal, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, and - Brian Wellington. - - No doubt the above list is incomplete. We apologize to anyone we - left out. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 22] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -14. References - -14.1 Normative References - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in - progress), May 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-08 (work in progress), - May 2004. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - -14.2 Informative References - - [I-D.ietf-dnsext-dns-threats] - Atkins, D. and R. Austein, "Threat Analysis Of The Domain - Name System", draft-ietf-dnsext-dns-threats-07 (work in - progress), April 2004. - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "KEY RR Secure Entry Point Flag", - draft-ietf-dnsext-nsec-rdata-05 (work in progress), March - 2004. - - - -Arends, et al. Expires November 15, 2004 [Page 23] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in - the Domain Name System (DNS)", RFC 2538, March 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) - Signing Authority", RFC 3008, November 2000. - - [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", RFC 3755, April 2004. - - [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", RFC 3757, April 2004. - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 24] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - -Arends, et al. Expires November 15, 2004 [Page 25] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires November 15, 2004 [Page 26] - -Internet-Draft DNSSEC Introduction and Requirements May 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 27] - - + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: January 13, 2005 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + July 15, 2004 + + + DNS Security Introduction and Requirements + draft-ietf-dnsext-dnssec-intro-11 + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 13, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + The Domain Name System Security Extensions (DNSSEC) add data origin + authentication and data integrity to the Domain Name System. This + + + +Arends, et al. Expires January 13, 2005 [Page 1] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + document introduces these extensions, and describes their + capabilities and limitations. This document also discusses the + services that the DNS security extensions do and do not provide. + Last, this document describes the interrelationships between the + group of documents that collectively describe DNSSEC. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 + 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 + 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 + 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9 + 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 + 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 + 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 + 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 + 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 + 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 + 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 + 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 + 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 + Intellectual Property and Copyright Statements . . . . . . . . 26 + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 2] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +1. Introduction + + This document introduces the Domain Name System Security Extensions + (DNSSEC). This document and its two companion documents + ([I-D.ietf-dnsext-dnssec-records] and + [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the + security extensions defined in RFC 2535 [RFC2535] and its + predecessors. These security extensions consist of a set of new + resource record types and modifications to the existing DNS protocol + [RFC1035]. The new records and protocol modifications are not fully + described in this document, but are described in a family of + documents outlined in Section 10. Section 3 and Section 4 describe + the capabilities and limitations of the security extensions in + greater detail. Section 5 discusses the scope of the document set. + Section 6, Section 7, Section 8, and Section 9 discuss the effect + that these security extensions will have on resolvers, stub + resolvers, zones and name servers. + + This document and its two companions update and obsolete RFCs 2535 + [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 + [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress + [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but + does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 + [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts + of 3226 [RFC3226] (dealing with DNSSEC). + + The DNS security extensions provide origin authentication and + integrity protection for DNS data, as well as a means of public key + distribution. These extensions do not provide confidentiality. + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 3] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +2. Definitions of Important DNSSEC Terms + + This section defines a number of terms used in this document set. + Since this is intended to be useful as a reference while reading the + rest of the document set, first-time readers may wish to skim this + section quickly, read the rest of this document, then come back to + this section. + + Authentication Chain: An alternating sequence of DNSKEY RRsets and DS + RRsets forms a chain of signed data, with each link in the chain + vouching for the next. A DNSKEY RR is used to verify the + signature covering a DS RR and allows the DS RR to be + authenticated. The DS RR contains a hash of another DNSKEY RR and + this new DNSKEY RR is authenticated by matching the hash in the DS + RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset + and, in turn, some DNSKEY RR in this set may be used to + authenticate another DS RR and so forth until the chain finally + ends with a DNSKEY RR whose corresponding private key signs the + desired DNS data. For example, the root DNSKEY RRset can be used + to authenticate the DS RRset for "example." The "example." DS + RRset contains a hash that matches some "example." DNSKEY, and + this DNSKEY's corresponding private key signs the "example." + DNSKEY RRset. Private key counterparts of the "example." DNSKEY + RRset sign data records such as "www.example." as well as DS RRs + for delegations such as "subzone.example." + + Authentication Key: A public key that a security-aware resolver has + verified and can therefore use to authenticate data. A + security-aware resolver can obtain authentication keys in three + ways. First, the resolver is generally configured to know about + at least one public key; this configured data is usually either + the public key itself or a hash of the public key as found in the + DS RR (see "trust anchor"). Second, the resolver may use an + authenticated public key to verify a DS RR and the DNSKEY RR to + which the DS RR refers. Third, the resolver may be able to + determine that a new public key has been signed by the private key + corresponding to another public key which the resolver has + verified. Note that the resolver must always be guided by local + policy when deciding whether to authenticate a new public key, + even if the local policy is simply to authenticate any new public + key for which the resolver is able verify the signature. + + Delegation Point: Term used to describe the name at the parental side + of a zone cut. That is, the delegation point for "foo.example" + would be the foo.example node in the "example" zone (as opposed to + the zone apex of the "foo.example" zone). + + + + + +Arends, et al. Expires January 13, 2005 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + Island of Security: Term used to describe a signed, delegated zone + that does not have an authentication chain from its delegating + parent. That is, there is no DS RR containing a hash of a DNSKEY + RR for the island in its delegating parent zone (see + [I-D.ietf-dnsext-dnssec-records]). An island of security is + served by security-aware name servers and may provide + authentication chains to any delegated child zones. Responses + from an island of security or its descendents can only be + authenticated if its authentication keys can be authenticated by + some trusted means out of band from the DNS protocol. + + Key Signing Key (KSK): An authentication key that corresponds to a + private key used to sign one or more other authentication keys for + a given zone. Typically, the private key corresponding to a key + signing key will sign a zone signing key, which in turn has a + corresponding private key which will sign other zone data. Local + policy may require the zone signing key to be changed frequently, + while the key signing key may have a longer validity period in + order to provide a more stable secure entry point into the zone. + Designating an authentication key as a key signing key is purely + an operational issue: DNSSEC validation does not distinguish + between key signing keys and other DNSSEC authentication keys, and + it is possible to use a single key as both a key signing key and a + zone signing key. Key signing keys are discussed in more detail + in [RFC3757]. Also see: zone signing key. + + Non-Validating Security-Aware Stub Resolver: A security-aware stub + resolver which trusts one or more security-aware recursive name + servers to perform most of the tasks discussed in this document + set on its behalf. In particular, a non-validating security-aware + stub resolver is an entity which sends DNS queries, receives DNS + responses, and is capable of establishing an appropriately secured + channel to a security-aware recursive name server which will + provide these services on behalf of the security-aware stub + resolver. See also: security-aware stub resolver, validating + security-aware stub resolver. + + Non-Validating Stub Resolver: A less tedious term for a + non-validating security-aware stub resolver. + + Security-Aware Name Server: An entity acting in the role of a name + server (defined in section 2.4 of [RFC1034]) that understands the + DNS security extensions defined in this document set. In + particular, a security-aware name server is an entity which + receives DNS queries, sends DNS responses, supports the EDNS0 + [RFC2671] message size extension and the DO bit [RFC3225], and + supports the RR types and message header bits defined in this + document set. + + + +Arends, et al. Expires January 13, 2005 [Page 5] + + + Security-Aware Recursive Name Server: An entity which acts in both + the security-aware name server and security-aware resolver roles. + A more cumbersome equivalent phrase would be "a security-aware + name server which offers recursive service". + + Security-Aware Resolver: An entity acting in the role of a resolver + (defined in section 2.4 of [RFC1034]) which understands the DNS + security extensions defined in this document set. In particular, + a security-aware resolver is an entity which sends DNS queries, + receives DNS responses, supports the EDNS0 [RFC2671] message size + extension and the DO bit [RFC3225], and is capable of using the RR + types and message header bits defined in this document set to + provide DNSSEC services. + + Security-Aware Stub Resolver: An entity acting in the role of a stub + resolver (defined in section 5.3.1 of [RFC1034]) which has enough + of an understanding the DNS security extensions defined in this + document set to provide additional services not available from a + security-oblivious stub resolver. Security-aware stub resolvers + may be either "validating" or "non-validating" depending on + whether the stub resolver attempts to verify DNSSEC signatures on + its own or trusts a friendly security-aware name server to do so. + See also: validating stub resolver, non-validating stub resolver. + + Security-Oblivious : An that is not + "security-aware". + + Signed Zone: A zone whose RRsets are signed and which contains + properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS + records. + + Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A + validating security-aware resolver uses this public key or hash as + a starting point for building the authentication chain to a signed + DNS response. In general, a validating resolver will need to + obtain the initial values of its trust anchors via some secure or + trusted means outside the DNS protocol. Presence of a trust + anchor also implies that the resolver should expect the zone to + which the trust anchor points to be signed. + + Unsigned Zone: A zone that is not signed. + + Validating Security-Aware Stub Resolver: A security-aware resolver + that sends queries in recursive mode but which performs signature + validation on its own rather than just blindly trusting an + upstream security-aware recursive name server. See also: + security-aware stub resolver, non-validating security-aware stub + resolver. + + + + + +Arends, et al. Expires January 13, 2005 [Page 6] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + Validating Stub Resolver: A less tedious term for a validating + security-aware stub resolver. + + Zone Signing Key (ZSK): An authentication key that corresponds to a + private key used to sign a zone. Typically a zone signing key + will be part of the same DNSKEY RRset as the key signing key whose + corresponding private key signs this DNSKEY RRset, but the zone + signing key is used for a slightly different purpose, and may + differ from the key signing key in other ways, such as validity + lifetime. Designating an authentication key as a zone signing key + is purely an operational issue: DNSSEC validation does not + distinguish between zone signing keys and other DNSSEC + authentication keys, and it is possible to use a single key as + both a key signing key and a zone signing key. See also: key + signing key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 7] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +3. Services Provided by DNS Security + + The Domain Name System (DNS) security extensions provide origin + authentication and integrity assurance services for DNS data, + including mechanisms for authenticated denial of existence of DNS + data. These mechanisms are described below. + + These mechanisms require changes to the DNS protocol. DNSSEC adds + four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two + new message header bits (CD and AD). In order to support the larger + DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also + requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support + for the DO bit [RFC3225], so that a security-aware resolver can + indicate in its queries that it wishes to receive DNSSEC RRs in + response messages. + + These services protect against most of the threats to the Domain Name + System described in [I-D.ietf-dnsext-dns-threats]. + +3.1 Data Origin Authentication and Data Integrity + + DNSSEC provides authentication by associating cryptographically + generated digital signatures with DNS RRsets. These digital + signatures are stored in a new resource record, the RRSIG record. + Typically, there will be a single private key that signs a zone's + data, but multiple keys are possible: for example, there may be keys + for each of several different digital signature algorithms. If a + security-aware resolver reliably learns a zone's public key, it can + authenticate that zone's signed data. An important DNSSEC concept is + that the key that signs a zone's data is associated with the zone + itself and not with the zone's authoritative name servers (public + keys for DNS transaction authentication mechanisms may also appear in + zones, as described in [RFC2931], but DNSSEC itself is concerned with + object security of DNS data, not channel security of DNS + transactions. The keys associated with transaction security may be + stored in different RR types. See [RFC3755] for details.). + + A security-aware resolver can learn a zone's public key either by + having a trust anchor configured into the resolver or by normal DNS + resolution. To allow the latter, public keys are stored in a new + type of resource record, the DNSKEY RR. Note that the private keys + used to sign zone data must be kept secure, and should be stored + offline when practical to do so. To discover a public key reliably + via DNS resolution, the target key itself needs to be signed by + either a configured authentication key or another key that has been + authenticated previously. Security-aware resolvers authenticate zone + information by forming an authentication chain from a newly learned + public key back to a previously known authentication public key, + + + +Arends, et al. Expires January 13, 2005 [Page 8] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + which in turn either has been configured into the resolver or must + have been learned and verified previously. Therefore, the resolver + must be configured with at least one trust anchor. If the configured + key is a zone signing key, then it will authenticate the associated + zone; if the configured key is a key signing key, it will + authenticate a zone signing key. If the resolver has been configured + with the hash of a key rather than the key itself, the resolver may + need to obtain the key via a DNS query. To help security-aware + resolvers establish this authentication chain, security-aware name + servers attempt to send the signature(s) needed to authenticate a + zone's public key(s) in the DNS reply message along with the public + key itself, provided there is space available in the message. + + The Delegation Signer (DS) RR type simplifies some of the + administrative tasks involved in signing delegations across + organizational boundaries. The DS RRset resides at a delegation + point in a parent zone and indicates the public key(s) corresponding + to the private key(s) used to self-sign the DNSKEY RRset at the + delegated child zone's apex. The administrator of the child zone, in + turn, uses the private key(s) corresponding to one or more of the + public keys in this DNSKEY RRset to sign the child zone's data. The + typical authentication chain is therefore + DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more + DS->DNSKEY subchains. DNSSEC permits more complex authentication + chains, such as additional layers of DNSKEY RRs signing other DNSKEY + RRs within a zone. + + A security-aware resolver normally constructs this authentication + chain from the root of the DNS hierarchy down to the leaf zones based + on configured knowledge of the public key for the root. Local + policy, however, may also allow a security-aware resolver to use one + or more configured public keys (or hashes of public keys) other than + the root public key, or may not provide configured knowledge of the + root public key, or may prevent the resolver from using particular + public keys for arbitrary reasons even if those public keys are + properly signed with verifiable signatures. DNSSEC provides + mechanisms by which a security-aware resolver can determine whether + an RRset's signature is "valid" within the meaning of DNSSEC. In the + final analysis however, authenticating both DNS keys and data is a + matter of local policy, which may extend or even override the + protocol extensions defined in this document set. See Section 5 for + further discussion. + +3.2 Authenticating Name and Type Non-Existence + + The security mechanism described in Section 3.1 only provides a way + to sign existing RRsets in a zone. The problem of providing negative + responses with the same level of authentication and integrity + + + +Arends, et al. Expires January 13, 2005 [Page 9] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + requires the use of another new resource record type, the NSEC + record. The NSEC record allows a security-aware resolver to + authenticate a negative reply for either name or type non-existence + via the same mechanisms used to authenticate other DNS replies. Use + of NSEC records requires a canonical representation and ordering for + domain names in zones. Chains of NSEC records explicitly describe + the gaps, or "empty space", between domain names in a zone, as well + as listing the types of RRsets present at existing names. Each NSEC + record is signed and authenticated using the mechanisms described in + Section 3.1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 10] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +4. Services Not Provided by DNS Security + + DNS was originally designed with the assumptions that the DNS will + return the same answer to any given query regardless of who may have + issued the query, and that all data in the DNS is thus visible. + Accordingly, DNSSEC is not designed to provide confidentiality, + access control lists, or other means of differentiating between + inquirers. + + DNSSEC provides no protection against denial of service attacks. + Security-aware resolvers and security-aware name servers are + vulnerable to an additional class of denial of service attacks based + on cryptographic operations. Please see Section 12 for details. + + The DNS security extensions provide data and origin authentication + for DNS data. The mechanisms outlined above are not designed to + protect operations such as zone transfers and dynamic update + [RFC3007]. Message authentication schemes described in [RFC2845] and + [RFC2931] address security operations that pertain to these + transactions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 11] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +5. Scope of the DNSSEC Document Set and Last Hop Issues + + The specification in this document set defines the behavior for zone + signers and security-aware name servers and resolvers in such a way + that the validating entities can unambiguously determine the state of + the data. + + A validating resolver can determine these 4 states: + + Secure: The validating resolver has a trust anchor, a chain of trust + and is able to verify all the signatures in the response. + + Insecure: The validating resolver has a trust anchor, a chain of + trust, and, at some delegation point, signed proof of the + non-existence of a DS record. That indicates that subsequent + branches in the tree are provably insecure. A validating resolver + may have local policy to mark parts of the domain space as + insecure. + + Bogus: The validating resolver has a trust anchor and there is a + secure delegation which is indicating that subsidiary data will be + signed, but the response fails to validate due to one or more + reasons: missing signatures, expired signatures, signatures with + unsupported algorithms, data missing which the relevant NSEC RR + says should be present, and so forth. + + Indeterminate: There is no trust anchor which would indicate that a + specific portion of the tree is secure. This is the default + operation mode. + + This specification only defines how security aware name servers can + signal non-validating stub resolvers that data was found to be bogus + (using RCODE=2, "Server Failure" -- see + [I-D.ietf-dnsext-dnssec-protocol]). + + There is a mechanism for security aware name servers to signal + security-aware stub resolvers that data was found to be secure (using + the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). + + This specification does not define a format for communicating why + responses were found to be bogus or marked as insecure. The current + signaling mechanism does not distinguish between indeterminate and + insecure. + + A method for signaling advanced error codes and policy between a + security aware stub resolver and security aware recursive nameservers + is a topic for future work, as is the interface between a security + aware resolver and the applications that use it. Note, however, that + + + +Arends, et al. Expires January 13, 2005 [Page 12] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + the lack of the specification of such communication does not prohibit + deployment of signed zones or the deployment of security aware + recursive name servers that prohibit propagation of bogus data to the + applications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 13] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +6. Resolver Considerations + + A security-aware resolver needs to be able to perform cryptographic + functions necessary to verify digital signatures using at least the + mandatory-to-implement algorithm(s). Security-aware resolvers must + also be capable of forming an authentication chain from a newly + learned zone back to an authentication key, as described above. This + process might require additional queries to intermediate DNS zones to + obtain necessary DNSKEY, DS and RRSIG records. A security-aware + resolver should be configured with at least one trust anchor as the + starting point from which it will attempt to establish authentication + chains. + + If a security-aware resolver is separated from the relevant + authoritative name servers by a recursive name server or by any sort + of device which acts as a proxy for DNS, and if the recursive name + server or proxy is not security-aware, the security-aware resolver + may not be capable of operating in a secure mode. For example, if a + security-aware resolver's packets are routed through a network + address translation device that includes a DNS proxy which is not + security-aware, the security-aware resolver may find it difficult or + impossible to obtain or validate signed DNS data. + + If a security-aware resolver must rely on an unsigned zone or a name + server that is not security aware, the resolver may not be able to + validate DNS responses, and will need a local policy on whether to + accept unverified responses. + + A security-aware resolver should take a signature's validation period + into consideration when determining the TTL of data in its cache, to + avoid caching signed data beyond the validity period of the + signature, but should also allow for the possibility that the + security-aware resolver's own clock is wrong. Thus, a security-aware + resolver which is part of a security-aware recursive name server will + need to pay careful attention to the DNSSEC "checking disabled" (CD) + bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid + blocking valid signatures from getting through to other + security-aware resolvers which are clients of this recursive name + server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure + recursive server handles queries with the CD bit set. + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 14] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +7. Stub Resolver Considerations + + Although not strictly required to do so by the protocol, most DNS + queries originate from stub resolvers. Stub resolvers, by + definition, are minimal DNS resolvers which use recursive query mode + to offload most of the work of DNS resolution to a recursive name + server. Given the widespread use of stub resolvers, the DNSSEC + architecture has to take stub resolvers into account, but the + security features needed in a stub resolver differ in some respects + from those needed in a full security-aware resolver. + + Even a security-oblivious stub resolver may get some benefit from + DNSSEC if the recursive name servers it uses are security-aware, but + for the stub resolver to place any real reliance on DNSSEC services, + the stub resolver must trust both the recursive name servers in + question and the communication channels between itself and those name + servers. The first of these issues is a local policy issue: in + essence, a security-oblivious stub resolver has no real choice but to + place itself at the mercy of the recursive name servers that it uses, + since it does not perform DNSSEC validity checks on its own. The + second issue requires some kind of channel security mechanism; proper + use of DNS transaction authentication mechanisms such as SIG(0) or + TSIG would suffice, as would appropriate use of IPsec, and particular + implementations may have other choices available, such as operating + system specific interprocess communication mechanisms. + Confidentiality is not needed for this channel, but data integrity + and message authentication are. + + A security-aware stub resolver that does trust both its recursive + name servers and its communication channel to them may choose to + examine the setting of the AD bit in the message header of the + response messages it receives. The stub resolver can use this flag + bit as a hint to find out whether the recursive name server was able + to validate signatures for all of the data in the Answer and + Authority sections of the response. + + There is one more step that a security-aware stub resolver can take + if, for whatever reason, it is not able to establish a useful trust + relationship with the recursive name servers which it uses: it can + perform its own signature validation, by setting the Checking + Disabled (CD) bit in its query messages. A validating stub resolver + is thus able to treat the DNSSEC signatures as a trust relationship + between the zone administrator and the stub resolver itself. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 15] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +8. Zone Considerations + + There are several differences between signed and unsigned zones. A + signed zone will contain additional security-related records (RRSIG, + DNSKEY, DS and NSEC records). RRSIG and NSEC records may be + generated by a signing process prior to serving the zone. The RRSIG + records that accompany zone data have defined inception and + expiration times, which establish a validity period for the + signatures and the zone data the signatures cover. + +8.1 TTL values vs. RRSIG validity period + + It is important to note the distinction between a RRset's TTL value + and the signature validity period specified by the RRSIG RR covering + that RRset. DNSSEC does not change the definition or function of the + TTL value, which is intended to maintain database coherency in + caches. A caching resolver purges RRsets from its cache no later + than the end of the time period specified by the TTL fields of those + RRsets, regardless of whether or not the resolver is security-aware. + + The inception and expiration fields in the RRSIG RR + [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time + period during which the signature can be used to validate the covered + RRset. The signatures associated with signed zone data are only + valid for the time period specified by these fields in the RRSIG RRs + in question. TTL values cannot extend the validity period of signed + RRsets in a resolver's cache, but the resolver may use the time + remaining before expiration of the signature validity period of a + signed RRset as an upper bound for the TTL of the signed RRset and + its associated RRSIG RR in the resolver's cache. + +8.2 New Temporal Dependency Issues for Zones + + Information in a signed zone has a temporal dependency which did not + exist in the original DNS protocol. A signed zone requires regular + maintenance to ensure that each RRset in the zone has a current valid + RRSIG RR. The signature validity period of an RRSIG RR is an + interval during which the signature for one particular signed RRset + can be considered valid, and the signatures of different RRsets in a + zone may expire at different times. Re-signing one or more RRsets in + a zone will change one or more RRSIG RRs, which in turn will require + incrementing the zone's SOA serial number to indicate that a zone + change has occurred and re-signing the SOA RRset itself. Thus, + re-signing any RRset in a zone may also trigger DNS NOTIFY messages + and zone transfers operations. + + + + + + +Arends, et al. Expires January 13, 2005 [Page 16] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +9. Name Server Considerations + + A security-aware name server should include the appropriate DNSSEC + records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from + resolvers which have signaled their willingness to receive such + records via use of the DO bit in the EDNS header, subject to message + size limitations. Since inclusion of these DNSSEC RRs could easily + cause UDP message truncation and fallback to TCP, a security-aware + name server must also support the EDNS "sender's UDP payload" + mechanism. + + If possible, the private half of each DNSSEC key pair should be kept + offline, but this will not be possible for a zone for which DNS + dynamic update has been enabled. In the dynamic update case, the + primary master server for the zone will have to re-sign the zone when + updated, so the private key corresponding to the zone signing key + will have to be kept online. This is an example of a situation where + the ability to separate the zone's DNSKEY RRset into zone signing + key(s) and key signing key(s) may be useful, since the key signing + key(s) in such a case can still be kept offline and may have a longer + useful lifetime than the zone signing key(s). + + DNSSEC, by itself, is not enough to protect the integrity of an + entire zone during zone transfer operations, since even a signed zone + contains some unsigned, nonauthoritative data if the zone has any + children. Therefore, zone maintenance operations will require some + additional mechanisms (most likely some form of channel security, + such as TSIG, SIG(0), or IPsec). + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 17] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +10. DNS Security Document Family + + The DNSSEC document set can be partitioned into several main groups, + under the larger umbrella of the DNS base protocol documents. + + The "DNSSEC protocol document set" refers to the three documents + which form the core of the DNS security extensions: + 1. DNS Security Introduction and Requirements (this document) + 2. Resource Records for DNS Security Extensions + [I-D.ietf-dnsext-dnssec-records] + 3. Protocol Modifications for the DNS Security Extensions + [I-D.ietf-dnsext-dnssec-protocol] + + Additionally, any document that would add to, or change the core DNS + Security extensions would fall into this category. This includes any + future work on the communication between security-aware stub + resolvers and upstream security-aware recursive name servers. + + The "Digital Signature Algorithm Specification" document set refers + to the group of documents that describe how specific digital + signature algorithms should be implemented to fit the DNSSEC resource + record format. Each document in this set deals with a specific + digital signature algorithm. + + The "Transaction Authentication Protocol" document set refers to the + group of documents that deal with DNS message authentication, + including secret key establishment and verification. While not + strictly part of the DNSSEC specification as defined in this set of + documents, this group is noted because of its relationship to DNSSEC. + + The final document set, "New Security Uses", refers to documents that + seek to use proposed DNS Security extensions for other security + related purposes. DNSSEC does not provide any direct security for + these new uses, but may be used to support them. Documents that fall + in this category include the use of DNS in the storage and + distribution of certificates [RFC2538]. + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 18] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +11. IANA Considerations + + This overview document introduces no new IANA considerations. Please + see [I-D.ietf-dnsext-dnssec-records] for a complete review of the + IANA considerations introduced by DNSSEC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 19] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +12. Security Considerations + + This document introduces the DNS security extensions and describes + the document set that contains the new security records and DNS + protocol modifications. The extensions provide data origin + authentication and data integrity using digital signatures over + resource record sets.This document discusses the capabilities and + limitations of these extensions. + + In order for a security-aware resolver to validate a DNS response, + all zones along the path from the trusted starting point to the zone + containing the response zones must be signed, and all name servers + and resolvers involved in the resolution process must be + security-aware, as defined in this document set. A security-aware + resolver cannot verify responses originating from an unsigned zone, + from a zone not served by a security-aware name server, or for any + DNS data which the resolver is only able to obtain through a + recursive name server which is not security-aware. If there is a + break in the authentication chain such that a security-aware resolver + cannot obtain and validate the authentication keys it needs, then the + security-aware resolver cannot validate the affected DNS data. + + This document briefly discusses other methods of adding security to a + DNS query, such as using a channel secured by IPsec or using a DNS + transaction authentication mechanism, but transaction security is not + part of DNSSEC per se. + + A non-validating security-aware stub resolver, by definition, does + not perform DNSSEC signature validation on its own, and thus is + vulnerable both to attacks on (and by) the security-aware recursive + name servers which perform these checks on its behalf and also to + attacks on its communication with those security-aware recursive name + servers. Non-validating security-aware stub resolvers should use + some form of channel security to defend against the latter threat. + The only known defense against the former threat would be for the + security-aware stub resolver to perform its own signature validation, + at which point, again by definition, it would no longer be a + non-validating security-aware stub resolver. + + DNSSEC does not protect against denial of service attacks. DNSSEC + makes DNS vulnerable to a new class of denial of service attacks + based on cryptographic operations against security-aware resolvers + and security-aware name servers, since an attacker can attempt to use + DNSSEC mechanisms to consume a victim's resources. This class of + attacks takes at least two forms. An attacker may be able to consume + resources in a security-aware resolver's signature validation code by + tampering with RRSIG RRs in response messages or by constructing + needlessly complex signature chains. An attacker may also be able to + + + +Arends, et al. Expires January 13, 2005 [Page 20] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + consume resources in a security-aware name server which supports DNS + dynamic update, by sending a stream of update messages that force the + security-aware name server to re-sign some RRsets in the zone more + frequently than would otherwise be necessary. + + DNSSEC does not provide confidentiality, due to a deliberate design + choice. + + DNSSEC introduces the ability for a hostile party to enumerate all + the names in a zone by following the NSEC chain. NSEC RRs assert + which names do not exist in a zone by linking from existing name to + existing name along a canonical ordering of all the names within a + zone. Thus, an attacker can query these NSEC RRs in sequence to + obtain all the names in a zone. While not an attack on the DNS + itself, this could allow an attacker to map network hosts or other + resources by enumerating the contents of a zone. + + DNSSEC introduces significant additional complexity to the DNS, and + thus introduces many new opportunities for implementation bugs and + misconfigured zones. In particular, enabling DNSSEC signature + validation in a resolver may cause entire legitimate zones to become + effectively unreachable due to DNSSEC configuration errors or bugs. + + DNSSEC does not protect against tampering with unsigned zone data. + Non-authoritative data at zone cuts (glue and NS RRs in the parent + zone) are not signed. This does not pose a problem when validating + the authentication chain, but does mean that the non-authoritative + data itself is vulnerable to tampering during zone transfer + operations. Thus, while DNSSEC can provide data origin + authentication and data integrity for RRsets, it cannot do so for + zones, and other mechanisms must be used to protect zone transfer + operations. + + Please see [I-D.ietf-dnsext-dnssec-records] and + [I-D.ietf-dnsext-dnssec-protocol] for additional security + considerations. + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 21] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +13. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group. While explicitly listing everyone + who has contributed during the decade during which DNSSEC has been + under development would be an impossible task, the editors would + particularly like to thank the following people for their + contributions to and comments on this document set: Jaap Akkerhuis, + Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, + David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald + Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, + Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip + Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, + Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon + Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, + Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, + Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ + Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, + Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob + Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and + Suzanne Woolf. + + No doubt the above list is incomplete. We apologize to anyone we + left out. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 22] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +14. References + +14.1 Normative References + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in + progress), May 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Resource Records for DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-08 (work in progress), + May 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + +14.2 Informative References + + [I-D.ietf-dnsext-dns-threats] + Atkins, D. and R. Austein, "Threat Analysis Of The Domain + Name System", draft-ietf-dnsext-dns-threats-07 (work in + progress), April 2004. + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "DNSSEC NSEC RDATA Format", + draft-ietf-dnsext-nsec-rdata-06 (work in progress), May + 2004. + + + +Arends, et al. Expires January 13, 2005 [Page 23] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in + the Domain Name System (DNS)", RFC 2538, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) + Signing Authority", RFC 3008, November 2000. + + [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", RFC 3755, April 2004. + + [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", RFC 3757, April 2004. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 24] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + +Arends, et al. Expires January 13, 2005 [Page 25] + +Internet-Draft DNSSEC Introduction and Requirements July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires January 13, 2005 [Page 26] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt similarity index 81% rename from doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt rename to doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt index a6f628e3c7..5728b35c9b 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt @@ -1,3249 +1,3193 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: November 15, 2004 M. Larson - VeriSign - R. Austein - ISC - D. Massey - USC/ISI - S. Rose - NIST - May 17, 2004 - - - Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-06 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 15, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document is part of a family of documents which describe the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of new resource records and protocol modifications which - add data origin authentication and data integrity to the DNS. This - document describes the DNSSEC protocol modifications. This document - - - -Arends, et al. Expires November 15, 2004 [Page 1] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - defines the concept of a signed zone, along with the requirements for - serving and resolving using DNSSEC. These techniques allow a - security-aware resolver to authenticate both DNS resource records and - authoritative DNS error indications. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . 4 - 1.3.2 Technical Changes or Corrections . . . . . . . . . . . 4 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . 5 - 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 6 - 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 6 - 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 7 - 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 8 - 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 8 - 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . 9 - 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 11 - 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 11 - 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 12 - 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 12 - 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 15 - 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 16 - 3.1.6 The AD and CD Bits in an Authoritative Response . . . 17 - 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 - 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 19 - 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 19 - 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.2 Signature Verification Support . . . . . . . . . . . . . . 20 - 4.3 Determining Security Status of Data . . . . . . . . . . . 21 - 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 21 - 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22 - 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22 - 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22 - 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23 - 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23 - 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 24 - - - -Arends, et al. Expires November 15, 2004 [Page 2] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 24 - 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24 - 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 - 5.1 Special Considerations for Islands of Security . . . . . . 26 - 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26 - 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27 - 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 - 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 - 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 - 5.3.4 Authenticating A Wildcard Expanded RRset Positive - Response . . . . . . . . . . . . . . . . . . . . . . . 31 - 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 - 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 - 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 - A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 - B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 - B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 - B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 - B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 - B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 - B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 - B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 - B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 - B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52 - C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54 - C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54 - C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54 - C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55 - C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55 - C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55 - C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55 - C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 - C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 - C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 - Intellectual Property and Copyright Statements . . . . . . . . 57 - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 3] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) are a collection of new resource - records and protocol modifications which add data origin - authentication and data integrity to the DNS. This document defines - the DNSSEC protocol modifications. Section 2 of this document defines - the concept of a signed zone and lists the requirements for zone - signing. Section 3 describes the modifications to authoritative name - server behavior necessary to handle signed zones. Section 4 describes - the behavior of entities which include security-aware resolver - functions. Finally, Section 5 defines how to use DNSSEC RRs to - authenticate a response. - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in [RFC1034] and [RFC1035]. - - This document is part of a family of documents that define DNSSEC. - An introduction to DNSSEC and definition of common terms can be found - in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC - resource records can be found in [I-D.ietf-dnsext-dnssec-records]. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. [RFC2119]. - -1.3 Editors' Notes - -1.3.1 Open Technical Issues - -1.3.2 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where no RFC that defines the correct behavior, or if there's - more than one applicable RFC and the definitions conflict, please - post the issue to namedroppers. - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - - - - -Arends, et al. Expires November 15, 2004 [Page 4] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -1.3.3 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to find - the incorrect text quickly. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 5] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -2. Zone Signing - - DNSSEC introduces the concept of signed zones. A signed zone - includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to - the rules specified in Section 2.1, Section 2.2, Section 2.3 and - Section 2.4, respectively. A zone that does not include these - records according to the rules in this section is an unsigned zone. - - DNSSEC requires a change to the definition of the CNAME resource - record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG - and NSEC RRs to appear at the same owner name as a CNAME RR. - -2.1 Including DNSKEY RRs in a Zone - - To sign a zone, the zone's administrator generates one or more - public/private key pairs and uses the private key(s) to sign - authoritative RRsets in the zone. For each private key used to - create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with - the public component stored in the zone. A zone key DNSKEY RR MUST - have the Zone Key bit of the flags RDATA field set to one -- see - Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys - associated with other DNS operations MAY be stored in DNSKEY RRs that - are not marked as zone keys but MUST NOT be used to verify RRSIGs. - - If the zone is delegated and does not wish to act as an island of - security, the zone MUST have at least one DNSKEY RR at the apex to - act as a secure entry point into the zone. This DNSKEY would then be - used to generate a DS RR at the delegating parent (see - [I-D.ietf-dnsext-dnssec-records]). - - DNSKEY RRs MUST NOT appear at delegation points. - -2.2 Including RRSIG RRs in a Zone - - For each authoritative RRset in a signed zone, there MUST be at least - one RRSIG record that meets all of the following requirements: - o The RRSIG owner name is equal to the RRset owner name; - o The RRSIG class is equal to the RRset class; - o The RRSIG Type Covered field is equal to the RRset type; - o The RRSIG Original TTL field is equal to the TTL of the RRset; - o The RRSIG RR's TTL is equal to the TTL of the RRset; - o The RRSIG Labels field is equal to the number of labels in the - RRset owner name, not counting the null root label and not - counting the leftmost label if it is a wildcard; - o The RRSIG Signer's Name field is equal to the name of the zone - containing the RRset; and - o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a - zone key DNSKEY record at the zone apex. - - - -Arends, et al. Expires November 15, 2004 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - The process for constructing the RRSIG RR for a given RRset is - described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have - multiple RRSIG RRs associated with it. - - An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR - would add no value and would create an infinite loop in the signing - process. - - The NS RRset that appears at the zone apex name MUST be signed, but - the NS RRsets that appear at delegation points (that is, the NS - RRsets in the parent zone that delegate the name to the child zone's - name servers) MUST NOT be signed. Glue address RRsets associated with - delegations MUST NOT be signed. - - There MUST be an RRSIG for each RRset using at least one DNSKEY of - each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset - itself MUST be signed by each algorithm appearing in the DS RRset - located at the delegating parent (if any). - -2.3 Including NSEC RRs in a Zone - - Each owner name in the zone which has authoritative data or a - delegation point NS RRset MUST have an NSEC resource record. The - process for constructing the NSEC RR for a given name is described in - [I-D.ietf-dnsext-dnssec-records]. - - The TTL value for any NSEC RR SHOULD be the same as the minimum TTL - value field in the zone SOA RR. - - An NSEC record (and its associated RRSIG RRset) MUST NOT be the only - RRset at any particular owner name. That is, the signing process - MUST NOT create NSEC or RRSIG RRs for owner names nodes which were - not the owner name of any RRset before the zone was signed. The main - reasons for this are a desire for namespace consistency between - signed and unsigned versions of the same zone and a desire to reduce - the risk of response inconsistency in security oblivious recursive - name servers. - - The type bitmap of every NSEC resource record in a signed zone MUST - indicate the presence of both the NSEC record itself and its - corresponding RRSIG record. - - The difference between the set of owner names that require RRSIG - records and the set of owner names that require NSEC records is - subtle and worth highlighting. RRSIG records are present at the - owner names of all authoritative RRsets. NSEC records are present at - the owner names of all names for which the signed zone is - authoritative and also at the owner names of delegations from the - - - -Arends, et al. Expires November 15, 2004 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - signed zone to its children. Neither NSEC nor RRSIG records are - present (in the parent zone) at the owner names of glue address - RRsets. Note, however, that this distinction is for the most part is - only visible during the zone signing process, because NSEC RRsets are - authoritative data, and are therefore signed, thus any owner name - which has an NSEC RRset will have RRSIG RRs as well in the signed - zone. - - The bitmap for the NSEC RR at a delegation point requires special - attention. Bits corresponding to the delegation NS RRset and the RR - types for which the parent zone has authoritative data MUST be set to - 1; bits corresponding to any non-NS RRset for which the parent is not - authoritative MUST be set to 0. - -2.4 Including DS RRs in a Zone - - The DS resource record establishes authentication chains between DNS - zones. A DS RRset SHOULD be present at a delegation point when the - child zone is signed. The DS RRset MAY contain multiple records, - each referencing a public key in the child zone used to verify the - RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS - RRsets MUST NOT appear at a zone's apex. - - A DS RR SHOULD point to a DNSKEY RR which is present in the child's - apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed - by the corresponding private key. - - The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset - (i.e., the NS RRset from the same zone containing the DS RRset). - - Construction of a DS RR requires knowledge of the corresponding - DNSKEY RR in the child zone, which implies communication between the - child and parent zones. This communication is an operational matter - not covered by this document. - -2.5 Changes to the CNAME Resource Record. - - If a CNAME RRset is present at a name in a signed zone, appropriate - RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that - name for secure dynamic update purposes is also allowed. Other types - MUST NOT be present at that name. - - This is a modification to the original CNAME definition given in - [RFC1034]. The original definition of the CNAME RR did not allow any - other types to coexist with a CNAME record, but a signed zone - requires NSEC and RRSIG RRs for every authoritative name. To resolve - this conflict, this specification modifies the definition of the - CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. - - - -Arends, et al. Expires November 15, 2004 [Page 8] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -2.6 Example of a Secure Zone - - Appendix A shows a complete example of a small signed zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 9] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -3. Serving - - This section describes the behavior of entities that include - security-aware name server functions. In many cases such functions - will be part of a security-aware recursive name server, but a - security-aware authoritative name server has some of the same - requirements. Functions specific to security-aware recursive name - servers are described in Section 3.2; functions specific to - authoritative servers are described in Section 3.1. - - The terms "SNAME", "SCLASS", and "STYPE" in the following discussion - are as used in [RFC1034]. - - A security-aware name server MUST support the EDNS0 [RFC2671] message - size extension, MUST support a message size of at least 1220 octets, - and SHOULD support a message size of 4000 octets [RFC3226]. - - A security-aware name server that receives a DNS query that does not - include the EDNS OPT pseudo-RR or that has the DO bit set to zero - MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other - RRset, and MUST NOT perform any of the additional processing - described below. Since the DS RR type has the peculiar property of - only existing in the parent zone at delegation points, DS RRs always - require some special processing, as described in Section 3.1.4.1. - - Security aware name servers that receive queries for security RR - types which match the content of more than one zone that it serves - (e.g. NSEC and RRSIG RRs above and below a delegation point where the - server is authoritative for both zones) are encouraged to behave - self-consistently. The name server MAY return one of the following: - o The above-delegation RRsets - o The below-delegation RRsets - o Both above and below-delegation RRsets - o Empty answer section (i.e. no records) - o Some other response - o An error - As long as the response is always consistent for each query to the - name server. - - DNSSEC allocates two new bits in the DNS message header: the CD - (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit - is controlled by resolvers; a security-aware name server MUST copy - the CD bit from a query into the corresponding response. The AD bit - is controlled by name servers; a security-aware name server MUST - ignore the setting of the AD bit in queries. See Section 3.1.6, - Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details - on the behavior of these bits. - - - - -Arends, et al. Expires November 15, 2004 [Page 10] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - A security aware name server which synthesizes CNAME RRs from DNAME - RRs as described in [RFC2672] SHOULD NOT generate signatures for the - synthesized CNAME RRs. - -3.1 Authoritative Name Servers - - Upon receiving a relevant query that has the EDNS [RFC2671] OPT - pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative - name server for a signed zone MUST include additional RRSIG, NSEC, - and DS RRs according to the following rules: - o RRSIG RRs that can be used to authenticate a response MUST be - included in the response according to the rules in Section 3.1.1; - o NSEC RRs that can be used to provide authenticated denial of - existence MUST be included in the response automatically according - to the rules in Section 3.1.3; - o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST - be included in referrals automatically according to the rules in - Section 3.1.4. - - DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 - discusses zone transfer requirements. - -3.1.1 Including RRSIG RRs in a Response - - When responding to a query that has the DO bit set to one, a - security-aware authoritative name server SHOULD attempt to send RRSIG - RRs that a security-aware resolver can use to authenticate the RRsets - in the response. A name server SHOULD make every attempt to keep the - RRset and its associated RRSIG(s) together in a response. Inclusion - of RRSIG RRs in a response is subject to the following rules: - o When placing a signed RRset in the Answer section, the name server - MUST also place its RRSIG RRs in the Answer section. The RRSIG - RRs have a higher priority for inclusion than any other RRsets - that may need to be included. If space does not permit inclusion - of these RRSIG RRs, the name server MUST set the TC bit. - o When placing a signed RRset in the Authority section, the name - server MUST also place its RRSIG RRs in the Authority section. - The RRSIG RRs have a higher priority for inclusion than any other - RRsets that may need to be included. If space does not permit - inclusion of these RRSIG RRs, the name server MUST set the TC bit. - o When placing a signed RRset in the Additional section, the name - server MUST also place its RRSIG RRs in the Additional section. - If space does not permit inclusion of both the RRset and its - associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If - this happens, the name server MUST NOT set the TC bit solely - because these RRSIG RRs didn't fit. - - - - - -Arends, et al. Expires November 15, 2004 [Page 11] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -3.1.2 Including DNSKEY RRs In a Response - - When responding to a query that has the DO bit set to one and that - requests the SOA or NS RRs at the apex of a signed zone, a - security-aware authoritative name server for that zone MAY return the - zone apex DNSKEY RRset in the Additional section. In this situation, - the DNSKEY RRset and associated RRSIG RRs have lower priority than - any other information that would be placed in the additional section. - The name server SHOULD NOT include the DNSKEY RRset unless there is - enough space in the response message for both the DNSKEY RRset and - its associated RRSIG RR(s). If there is not enough space to include - these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST - NOT set the TC bit solely because these RRs didn't fit (see Section - 3.1.1). - -3.1.3 Including NSEC RRs In a Response - - When responding to a query that has the DO bit set to one, a - security-aware authoritative name server for a signed zone MUST - include NSEC RRs in each of the following cases: - - No Data: The zone contains RRsets that exactly match , - but does not contain any RRsets that exactly match . - - Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. - - Wildcard Answer: The zone does not contain any RRsets that exactly - match but does contain an RRset that matches - via wildcard name expansion. - - Wildcard No Data: The zone does not contain any RRsets that exactly - match , does contain one or more RRsets that match - via wildcard name expansion, but does not contain - any RRsets that match 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 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 but contains no - RRset matching , then the name server MUST - include the NSEC RR for 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 - 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 ; and - o An NSEC RR proving that the zone contains no RRsets that would - match 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 but does contain an RRset which matches 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 . 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 , and while the zone does - contain RRsets which match 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 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 . - - 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 , but in cases such as the response - form described in Section 3.1.3.2 the appropriate cache index will be - the double . - -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 have failed to - validate exceeds a threshold value. - - Resolvers MUST NOT return RRsets from the BAD cache unless the - resolver is not required to validate the signatures of the RRsets in - question under the rules given in Section 4.2 of this document. See - Section 3.2.2 for discussion of how the responses returned by a - security-aware recursive name server interact with a BAD cache. - -4.8 Synthesized CNAMEs - - A validating security-aware resolver MUST treat the signature of a - valid signed DNAME RR as also covering unsigned CNAME RRs which could - have been synthesized from the DNAME RR as described in [RFC2672], at - least to the extent of not rejecting a response message solely - because it contains such CNAME RRs. The resolver MAY retain such - CNAME RRs in its cache or in the answers it hands back, but is not - required to do so. - -4.9 Stub resolvers - - A security-aware stub resolver MUST support the DNSSEC RR types, at - least to the extent of not mishandling responses just because they - contain DNSSEC RRs. - - - - - -Arends, et al. Expires November 15, 2004 [Page 23] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -4.9.1 Handling of the DO Bit - - A non-validating security-aware stub resolver MAY include the DNSSEC - RRs returned by a security-aware recursive name server as part of the - data that the stub resolver hands back to the application which - invoked it but is not required to do so. A non-validating stub - resolver that wishes to do this will need to set the DO bit in - receive DNSSEC RRs from the recursive name server. - - A validating security-aware stub resolver MUST set the DO bit, since - otherwise it will not receive the DNSSEC RRs it needs to perform - signature validation. - -4.9.2 Handling of the CD Bit - - A non-validating security-aware stub resolver SHOULD NOT set the CD - bit when sending queries unless requested by the application layer, - since by definition, a non-validating stub resolver depends on the - security-aware recursive name server to perform validation on its - behalf. - - A validating security-aware stub resolver SHOULD set the CD bit, - since otherwise the security-aware recursive name server will answer - the query using the name server's local policy, which may prevent the - stub resolver from receiving data which would be acceptable to the - stub resolver's local policy. - -4.9.3 Handling of the AD Bit - - A non-validating security-aware stub resolver MAY chose to examine - the setting of the AD bit in response messages that it receives in - order to determine whether the security-aware recursive name server - which sent the response claims to have cryptographically verified the - data in the Answer and Authority sections of the response message. - Note, however, that the responses received by a security-aware stub - resolver are heavily dependent on the local policy of the - security-aware recursive name server, so as a practical matter there - may be little practical value to checking the status of the AD bit - except perhaps as a debugging aid. In any case, a security-aware - stub resolver MUST NOT place any reliance on signature validation - allegedly performed on its behalf except when the security-aware stub - resolver obtained the data in question from a trusted security-aware - recursive name server via a secure channel. - - A validating security-aware stub resolver SHOULD NOT examine the - setting of the AD bit in response messages, since, by definition, the - stub resolver performs its own signature validation regardless of the - setting of the AD bit. - - - -Arends, et al. Expires November 15, 2004 [Page 24] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -5. Authenticating DNS Responses - - In order to use DNSSEC RRs for authentication, a security-aware - resolver requires configured knowledge of at least one authenticated - DNSKEY or DS RR. The process for obtaining and authenticating this - initial trust anchors is achieved via some external mechanism. For - example, a resolver could use some off-line authenticated exchange to - obtain a zone's DNSKEY RR or obtain a DS RR that identifies and - authenticates a zone's DNSKEY RR. The remainder of this section - assumes that the resolver has somehow obtained an initial set of - trust anchors. - - An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY - RRset. To authenticate an apex DNSKEY RRset using an initial key, - the resolver MUST: - 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag - (DNSKEY RDATA bit 7) set to one. - 2. Verify that there is some RRSIG RR that covers the apex DNSKEY - RRset, and that the combination of the RRSIG RR and the initial - DNSKEY RR authenticates the DNSKEY RRset. The process for using - an RRSIG RR to authenticate an RRset is described in Section 5.3. - - Once the resolver has authenticated the apex DNSKEY RRset using an - initial DNSKEY RR, delegations from that zone can be authenticated - using DS RRs. This allows a resolver to start from an initial key, - and use DS RRsets to proceed recursively down the DNS tree obtaining - other apex DNSKEY RRsets. If the resolver were configured with a - root DNSKEY RR, and if every delegation had a DS RR associated with - it, then the resolver could obtain and validate any apex DNSKEY - RRset. The process of using DS RRs to authenticate referrals is - described in Section 5.2. - - Once the resolver has authenticated a zone's apex DNSKEY RRset, - Section 5.3 shows how the resolver can use DNSKEY RRs in the apex - DNSKEY RRset and RRSIG RRs from the zone to authenticate any other - RRsets in the zone. Section 5.4 shows how the resolver can use - authenticated NSEC RRsets from the zone to prove that an RRset is not - present in the zone. - - When a resolver indicates support for DNSSEC (by setting the DO bit), - a security-aware name server should attempt to provide the necessary - DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). - However, a security-aware resolver may still receive a response that - that lacks the appropriate DNSSEC RRs, whether due to configuration - issues such as an upstream security-oblivious recursive name server - that accidentally interferes with DNSSEC RRs or due to a deliberate - attack in which an adversary forges a response, strips DNSSEC RRs - - - -Arends, et al. Expires November 15, 2004 [Page 25] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - from a response, or modifies a query so that DNSSEC RRs appear not to - be requested. The absence of DNSSEC data in a response MUST NOT by - itself be taken as an indication that no authentication information - exists. - - A resolver SHOULD expect authentication information from signed - zones. A resolver SHOULD believe that a zone is signed if the - resolver has been configured with public key information for the - zone, or if the zone's parent is signed and the delegation from the - parent contains a DS RRset. - -5.1 Special Considerations for Islands of Security - - Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed - zones for which it is not possible to construct an authentication - chain to the zone from its parent. Validating signatures within an - island of security requires the validator to have some other means of - obtaining an initial authenticated zone key for the island. If a - validator cannot obtain such a key, it SHOULD switch to operating as - if the zones in the island of security are unsigned. - - All the normal processes for validating responses apply to islands of - security. The only difference between normal validation and - validation within an island of security is in how the validator - obtains a trust anchor for the authentication chain. - -5.2 Authenticating Referrals - - Once the apex DNSKEY RRset for a signed parent zone has been - authenticated, DS RRsets can be used to authenticate the delegation - to a signed child zone. A DS RR identifies a DNSKEY RR in the child - zone's apex DNSKEY RRset, and contains a cryptographic digest of the - child zone's DNSKEY RR. A strong cryptographic digest algorithm - ensures that an adversary can not easily generate a DNSKEY RR that - matches the digest. Thus, authenticating the digest allows a - resolver to authenticate the matching DNSKEY RR. The resolver can - then use this child DNSKEY RR to authenticate the entire child apex - DNSKEY RRset. - - Given a DS RR for a delegation, the child zone's apex DNSKEY RRset - can be authenticated if all of the following hold: - o The DS RR has been authenticated using some DNSKEY RR in the - parent's apex DNSKEY RRset (see Section 5.3); - o The Algorithm and Key Tag in the DS RR match the Algorithm field - and the key tag of a DNSKEY RR in the child zone's apex DNSKEY - RRset and, when hashed using the digest algorithm specified in the - DS RR's Digest Type field, results in a digest value that matches - the Digest field of the DS RR; and - - - -Arends, et al. Expires November 15, 2004 [Page 26] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - o The matching DNSKEY RR in the child zone has the Zone Flag bit set - to one, the corresponding private key has signed the child zone's - apex DNSKEY RRset, and the resulting RRSIG RR authenticates the - child zone's apex DNSKEY RRset. - - If the referral from the parent zone did not contain a DS RRset, the - response should have included a signed NSEC RRset proving that no DS - RRset exists for the delegated name (see Section 3.1.4). A - security-aware resolver MUST query the name servers for the parent - zone for the DS RRset if the referral includes neither a DS RRset nor - a NSEC RRset proving that the DS RRset does not exist (see Section - 4). - - If the validator authenticates an NSEC RRset that proves that no DS - RRset is present for this zone, then there is no authentication path - leading from the parent to the child. If the resolver has an initial - DNSKEY or DS RR that belongs to the child zone or to any delegation - below the child zone, this initial DNSKEY or DS RR MAY be used to - re-establish an authentication path. If no such initial DNSKEY or DS - RR exists, the validator can not authenticate RRsets in or below the - child zone. - - If the validator does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver has no supported - authentication path leading from the parent to the child. The - resolver should treat this case as it would the case of an - authenticated NSEC RRset proving that no DS RRset exists, as - described above. - - Note that, for a signed delegation, there are two NSEC RRs associated - with the delegated name. One NSEC RR resides in the parent zone, and - can be used to prove whether a DS RRset exists for the delegated - name. The second NSEC RR resides in the child zone, and identifies - which RRsets are present at the apex of the child zone. The parent - NSEC RR and child NSEC RR can always be distinguished, since the SOA - bit will be set in the child NSEC RR and clear in the parent NSEC RR. - A security-aware resolver MUST use the parent NSEC RR when attempting - to prove that a DS RRset does not exist. - - If the resolver does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver will not be able to verify - the authentication path to the child zone. In this case, the - resolver SHOULD treat the child zone as if it were unsigned. - -5.3 Authenticating an RRset Using an RRSIG RR - - A validator can use an RRSIG RR and its corresponding DNSKEY RR to - attempt to authenticate RRsets. The validator first checks the RRSIG - - - -Arends, et al. Expires November 15, 2004 [Page 27] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - RR to verify that it covers the RRset, has a valid time interval, and - identifies a valid DNSKEY RR. The validator then constructs the - canonical form of the signed data by appending the RRSIG RDATA - (excluding the Signature Field) with the canonical form of the - covered RRset. Finally, the validator uses the public key and - signature to authenticate the signed data. Section 5.3.1, Section - 5.3.2, and Section 5.3.3 describe each step in detail. - -5.3.1 Checking the RRSIG RR Validity - - A security-aware resolver can use an RRSIG RR to authenticate an - RRset if all of the following conditions hold: - o The RRSIG RR and the RRset MUST have the same owner name and the - same class; - o The RRSIG RR's Signer's Name field MUST be the name of the zone - that contains the RRset; - o The RRSIG RR's Type Covered field MUST equal the RRset's type; - o The number of labels in the RRset owner name MUST be greater than - or equal to the value in the RRSIG RR's Labels field; - o The validator's notion of the current time MUST be less than or - equal to the time listed in the RRSIG RR's Expiration field; - o The validator's notion of the current time MUST be greater than or - equal to the time listed in the RRSIG RR's Inception field; - o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST - match the owner name, algorithm, and key tag for some DNSKEY RR in - the zone's apex DNSKEY RRset; - o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY - RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) - set to one. - - It is possible for more than one DNSKEY RR to match the conditions - above. In this case, the validator cannot predetermine which DNSKEY - RR to use to authenticate the signature, MUST try each matching - DNSKEY RR until either the signature is validated or the validator - has run out of matching public keys to try. - - Note that this authentication process is only meaningful if the - validator authenticates the DNSKEY RR before using it to validate - signatures. The matching DNSKEY RR is considered to be authentic if: - o The apex DNSKEY RRset containing the DNSKEY RR is considered - authentic; or - o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, - and the DNSKEY RR either matches an authenticated DS RR from the - parent zone or matches a trust anchor. - -5.3.2 Reconstructing the Signed Data - - Once the RRSIG RR has met the validity requirements described in - - - -Arends, et al. Expires November 15, 2004 [Page 28] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - Section 5.3.1, the validator needs to reconstruct the original signed - data. The original signed data includes RRSIG RDATA (excluding the - Signature field) and the canonical form of the RRset. Aside from - being ordered, the canonical form of the RRset might also differ from - the received RRset due to DNS name compression, decremented TTLs, or - wildcard expansion. The validator should use the following to - reconstruct the original signed data: - - signed_data = RRSIG_RDATA | RR(1) | RR(2)... where - - "|" denotes concatenation - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signature field excluded and the Signer's Name - in canonical form. - - RR(i) = name | type | class | OrigTTL | RDATA length | RDATA - - name is calculated according to the function below - - class is the RRset's class - - type is the RRset type and all RRs in the class - - OrigTTL is the value from the RRSIG Original TTL field - - All names in the RDATA field are in canonical form - - The set of all RR(i) is sorted into canonical order. - - To calculate the name: - let rrsig_labels = the value of the RRSIG Labels field - - let fqdn = RRset's fully qualified domain name in - canonical form - - let fqdn_labels = Label count of the fqdn above. - - if rrsig_labels = fqdn_labels, - name = fqdn - - if rrsig_labels < fqdn_labels, - name = "*." | the rightmost rrsig_label labels of the - fqdn - - if rrsig_labels > fqdn_labels - the RRSIG RR did not pass the necessary validation - checks and MUST NOT be used to authenticate this - - - -Arends, et al. Expires November 15, 2004 [Page 29] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - RRset. - - The canonical forms for names and RRsets are defined in - [I-D.ietf-dnsext-dnssec-records]. - - NSEC RRsets at a delegation boundary require special processing. - There are two distinct NSEC RRsets associated with a signed delegated - name. One NSEC RRset resides in the parent zone, and specifies which - RRset are present at the parent zone. The second NSEC RRset resides - at the child zone, and identifies which RRsets are present at the - apex in the child zone. The parent NSEC RRset and child NSEC RRset - can always be distinguished since only the child NSEC RRs will - specify an SOA RRset exists at the name. When reconstructing the - original NSEC RRset for the delegation from the parent zone, the NSEC - RRs MUST NOT be combined with NSEC RRs from the child zone, and when - reconstructing the original NSEC RRset for the apex of the child - zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent - zone. - - Note also that each of the two NSEC RRsets at a delegation point has - a corresponding RRSIG RR with an owner name matching the delegated - name, and each of these RRSIG RRs is authoritative data associated - with the same zone that contains the corresponding NSEC RRset. If - necessary, a resolver can tell these RRSIG RRs apart by checking the - Signer's Name field. - -5.3.3 Checking the Signature - - Once the resolver has validated the RRSIG RR as described in Section - 5.3.1 and reconstructed the original signed data as described in - Section 5.3.2, the validator can attempt to use the cryptographic - signature to authenticate the signed data, and thus (finally!) - authenticate the RRset. - - The Algorithm field in the RRSIG RR identifies the cryptographic - algorithm used to generate the signature. The signature itself is - contained in the Signature field of the RRSIG RDATA, and the public - key used to verify the signature is contained in the Public Key field - of the matching DNSKEY RR(s) (found in Section 5.3.1). - [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types - and provides pointers to the documents that define each algorithm's - use. - - Note that it is possible for more than one DNSKEY RR to match the - conditions in Section 5.3.1. In this case, the validator can only - determine which DNSKEY RR by trying each matching public key until - the validator either succeeds in validating the signature or runs out - of keys to try. - - - -Arends, et al. Expires November 15, 2004 [Page 30] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - If the Labels field of the RRSIG RR is not equal to the number of - labels in the RRset's fully qualified owner name, then the RRset is - either invalid or the result of wildcard expansion. The resolver - MUST verify that wildcard expansion was applied properly before - considering the RRset to be authentic. Section 5.3.4 describes how - to determine whether a wildcard was applied properly. - - If other RRSIG RRs also cover this RRset, the local resolver security - policy determines whether the resolver also needs to test these RRSIG - RRs, and determines how to resolve conflicts if these RRSIG RRs lead - to differing results. - - If the resolver accepts the RRset as authentic, the validator MUST - set the TTL of the RRSIG RR and each RR in the authenticated RRset to - a value no greater than the minimum of: - o The RRset's TTL as received in the response; - o The RRSIG RR's TTL as received in the response; - o The value in the RRSIG RR's Original TTL field; and - o The difference of the RRSIG RR's Signature Expiration time and the - current time. - -5.3.4 Authenticating A Wildcard Expanded RRset Positive Response - - If the number of labels in an RRset's owner name is greater than the - Labels field of the covering RRSIG RR, then the RRset and its - covering RRSIG RR were created as a result of wildcard expansion. - Once the validator has verified the signature as described in Section - 5.3, it must take additional steps to verify the non-existence of an - exact match or closer wildcard match for the query. Section 5.4 - discusses these steps. - - Note that the response received by the resolver should include all - NSEC RRs needed to authenticate the response (see Section 3.1.3). - -5.4 Authenticated Denial of Existence - - A resolver can use authenticated NSEC RRs to prove that an RRset is - not present in a signed zone. Security-aware name servers should - automatically include any necessary NSEC RRs for signed zones in - their responses to security-aware resolvers. - - Security-aware resolvers MUST first authenticate NSEC RRsets - according to the standard RRset authentication rules described in - Section 5.3, then apply the NSEC RRsets as follows: - o If the requested RR name matches the owner name of an - authenticated NSEC RR, then the NSEC RR's type bit map field lists - all RR types present at that owner name, and a resolver can prove - that the requested RR type does not exist by checking for the RR - - - -Arends, et al. Expires November 15, 2004 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - type in the bit map. If the number of labels in an authenticated - NSEC RR's owner name equals the Labels field of the covering RRSIG - RR, then the existence of the NSEC RR proves that wildcard - expansion could not have been used to match the request. - o If the requested RR name would appear after an authenticated NSEC - RR's owner name and before the name listed in that NSEC RR's Next - Domain Name field according to the canonical DNS name order - defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with - the requested name exist in the zone. However, it is possible - that a wildcard could be used to match the requested RR owner name - and type, so proving that the requested RRset does not exist also - requires proving that no possible wildcard RRset exists that could - have been used to generate a positive response. - - To prove non-existence of an RRset, the resolver must be able to - verify both that the queried RRset does not exist and that no - relevant wildcard RRset exists. Proving this may require more than - one NSEC RRset from the zone. If the complete set of necessary NSEC - RRsets is not present in a response (perhaps due to message - truncation), then a security-aware resolver MUST resend the query in - order to attempt to obtain the full collection of NSEC RRs necessary - to verify non-existence of the requested RRset. As with all DNS - operations, however, the resolver MUST bound the work it puts into - answering any particular query. - - Since a validated NSEC RR proves the existence of both itself and its - corresponding RRSIG RR, a validator MUST ignore the settings of the - NSEC and RRSIG bits in an NSEC RR. - -5.5 Resolver Behavior When Signatures Do Not Validate - - If for whatever reason none of the RRSIGs can be validated, the - response SHOULD be considered BAD. If the validation was being done - to service a recursive query, the name server MUST return RCODE 2 to - the originating client. However, it MUST return the full response if - and only if the original query had the CD bit set. See also Section - 4.7 on caching responses that do not validate. - -5.6 Authentication Example - - Appendix C shows an example the authentication process. - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 32] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -6. IANA Considerations - - [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA - considerations introduced by DNSSEC. The additional IANA - considerations discussed in this document: - - [RFC2535] reserved the CD and AD bits in the message header. The - meaning of the AD bit was redefined in [RFC3655] and the meaning of - both the CD and AD bit are restated in this document. No new bits in - the DNS message header are defined in this document. - - [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit - and defined its use. The use is restated but not altered in this - document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 33] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -7. Security Considerations - - This document describes how the DNS security extensions use public - key cryptography to sign and authenticate DNS resource record sets. - Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general - security considerations related to DNSSEC; see - [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the - DNSSEC resource record types. - - An active attacker who can set the CD bit in a DNS query message or - the AD bit in a DNS response message can use these bits to defeat the - protection which DNSSEC attempts to provide to security-oblivious - recursive-mode resolvers. For this reason, use of these control bits - by a security-aware recursive-mode resolver requires a secure - channel. See Section 3.2.2 and Section 4.9 for further discussion. - - The protocol described in this document attempts to extend the - benefits of DNSSEC to security-oblivious stub resolvers. However, - since recovery from validation failures is likely to be specific to - particular applications, the facilities that DNSSEC provides for stub - resolvers may prove inadequate. Operators of security-aware - recursive name servers will need to pay close attention to the - behavior of the applications which use their services when choosing a - local validation policy; failure to do so could easily result in the - recursive name server accidentally denying service to the clients it - is intended to support. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 34] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -8. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 35] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -9. References - -9.1 Normative References - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-10 (work in progress), May - 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-08 (work in progress), - May 2004. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC - 2672, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - -9.2 Informative References - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "KEY RR Secure Entry Point Flag", - draft-ietf-dnsext-nsec-rdata-05 (work in progress), March - - - -Arends, et al. Expires November 15, 2004 [Page 36] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - 2004. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - -Arends, et al. Expires November 15, 2004 [Page 37] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 38] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -Appendix A. Signed Zone Example - - The following example shows a (small) complete signed zone. - - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - 3600 NS ns1.example. - 3600 NS ns2.example. - 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - 3600 MX 1 xx.example. - 3600 RRSIG MX 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB - 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE - VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO - 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM - W6OISukd1EQt7a0kygkg+PEDxdI= ) - 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - 3600 DNSKEY 256 3 5 ( - AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV - rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e - k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo - vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI - - - -Arends, et al. Expires November 15, 2004 [Page 39] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== - ) - 3600 DNSKEY 257 3 5 ( - AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl - LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ - syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP - RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT - Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== - ) - 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( - 20040409183619 9465 example. - ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ - xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ - XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 - hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY - NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) - 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z - DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri - bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp - eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk - 7z5OXogYVaFzHKillDt3HRxHIZM= ) - a.example. 3600 IN NS ns1.a.example. - 3600 IN NS ns2.a.example. - 3600 DS 57855 5 1 ( - B6DCD485719ADCA18E5F3D48A2331627FDD3 - 636B ) - 3600 RRSIG DS 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ - oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH - kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD - EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ - Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) - 3600 NSEC ai.example. NS DS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba - U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 - 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I - BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g - sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - ai.example. 3600 IN A 192.0.2.9 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - - - -Arends, et al. Expires November 15, 2004 [Page 40] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B - ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd - hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u - ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy - 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) - 3600 HINFO "KLH-10" "ITS" - 3600 RRSIG HINFO 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l - e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh - ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 - AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw - FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) - 3600 AAAA 2001:db8::f00:baa9 - 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK - kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh - 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T - cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 - sZM6QjBBLmukH30+w1z3h8PUP2o= ) - 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG - CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p - P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN - 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL - AhS+JOVfDI/79QtyTI0SaDWcg8U= ) - b.example. 3600 IN NS ns1.b.example. - 3600 IN NS ns2.b.example. - 3600 NSEC ns1.example. NS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - ns1.example. 3600 IN A 192.0.2.1 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet - 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 - im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ - +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK - - - -Arends, et al. Expires November 15, 2004 [Page 41] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - v/iVXSYC0b7mPSU+EOlknFpVECs= ) - 3600 NSEC ns2.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 - 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB - jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq - ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 - IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) - ns2.example. 3600 IN A 192.0.2.2 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq - Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu - yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO - 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq - rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) - 3600 NSEC *.w.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE - VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb - 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH - l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw - Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) - *.w.example. 3600 IN MX 1 ai.example. - 3600 RRSIG MX 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 - f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc - tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X - TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw - 4kX18MMR34i8lC36SR5xBni8vHI= ) - 3600 NSEC x.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 - HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU - 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx - 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 - s1InQ2UoIv6tJEaaKkP701j8OLA= ) - x.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 - XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP - H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I - kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 - - - -Arends, et al. Expires November 15, 2004 [Page 42] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) - 3600 NSEC x.y.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK - vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E - mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI - NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e - IjgiM8PXkBQtxPq37wDKALkyn7Q= ) - x.y.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia - t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj - q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq - GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb - +gLcMZBnHJ326nb/TOOmrqNmQQE= ) - 3600 NSEC xx.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - xx.example. 3600 IN A 192.0.2.10 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP - 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa - 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y - VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx - kbIDV6GPPSZVusnZU6OMgdgzHV4= ) - 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 - t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq - BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 - 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ - RgNvuwbioFSEuv2pNlkq0goYxNY= ) - 3600 AAAA 2001:db8::f00:baaa - 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C - aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z - ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr - U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ - - - -Arends, et al. Expires November 15, 2004 [Page 43] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - xS9cL2QgW7FChw16mzlkH6/vsfs= ) - 3600 NSEC example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY - 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k - mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi - asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W - GghLahumFIpg4MO3LS/prgzVVWo= ) - - The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA - Flags indicate that each of these DNSKEY RRs is a zone key. One of - these DNSKEY RRs also has the SEP flag set and has been used to sign - the apex DNSKEY RRset; this is the key which should be hashed to - generate a DS record to be inserted into the parent zone. The other - DNSKEY is used to sign all the other RRsets in the zone. - - The zone includes a wildcard entry "*.w.example". Note that the name - "*.w.example" is used in constructing NSEC chains, and that the RRSIG - covering the "*.w.example" MX RRset has a label count of 2. - - The zone also includes two delegations. The delegation to - "b.example" includes an NS RRset, glue address records, and an NSEC - RR; note that only the NSEC RRset is signed. The delegation to - "a.example" provides a DS RR; note that only the NSEC and DS RRsets - are signed. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 44] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -Appendix B. Example Responses - - The examples in this section show response messages using the signed - zone example in Appendix A. - -B.1 Answer - - A successful query to an authoritative server. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - x.w.example. IN MX - - ;; Answer - x.w.example. 3600 IN MX 1 xx.example. - x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 - XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP - H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I - kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 - jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - - ;; Additional - xx.example. 3600 IN A 192.0.2.10 - xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP - 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa - 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y - VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx - kbIDV6GPPSZVusnZU6OMgdgzHV4= ) - xx.example. 3600 AAAA 2001:db8::f00:baaa - xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C - - - -Arends, et al. Expires November 15, 2004 [Page 45] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z - ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr - U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ - xS9cL2QgW7FChw16mzlkH6/vsfs= ) - ns1.example. 3600 IN A 192.0.2.1 - ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet - 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 - im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ - +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK - v/iVXSYC0b7mPSU+EOlknFpVECs= ) - ns2.example. 3600 IN A 192.0.2.2 - ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq - Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu - yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO - 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq - rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) - - -B.2 Name Error - - An authoritative name error. The NSEC RRs prove that the name does - not exist and that no covering wildcard exists. - - ;; Header: QR AA DO RCODE=3 - ;; - ;; Question - ml.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - - - -Arends, et al. Expires November 15, 2004 [Page 46] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - - ;; Additional - ;; (empty) - - -B.3 No Data Error - - A "NODATA" response. The NSEC RR proves that the name exists and - that the requested RR type does not. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 47] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - ns1.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC - ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 - 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB - jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq - ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 - IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) - - ;; Additional - ;; (empty) - - -B.4 Referral to Signed Zone - - Referral to a signed zone. The DS RR contains the data which the - resolver will need to validate the corresponding DNSKEY RR in the - child zone's apex. - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 48] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.a.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - a.example. 3600 IN NS ns1.a.example. - a.example. 3600 IN NS ns2.a.example. - a.example. 3600 DS 57855 5 1 ( - B6DCD485719ADCA18E5F3D48A2331627FDD3 - 636B ) - a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ - oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH - kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD - EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ - Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) - - ;; Additional - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - - -B.5 Referral to Unsigned Zone - - Referral to an unsigned zone. The NSEC RR proves that no DS RR for - this delegation exists in the parent zone. - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 49] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.b.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - b.example. 3600 IN NS ns1.b.example. - b.example. 3600 IN NS ns2.b.example. - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - - ;; Additional - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - - -B.6 Wildcard Expansion - - A successful query which was answered via wildcard expansion. The - label count in the answer's RRSIG RR indicates that a wildcard RRset - was expanded to produce this response, and the NSEC RR proves that no - closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN MX - - ;; Answer - a.z.w.example. 3600 IN MX 1 ai.example. - a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 - f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc - tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X - TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw - 4kX18MMR34i8lC36SR5xBni8vHI= ) - - ;; Authority - - - -Arends, et al. Expires November 15, 2004 [Page 50] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - - ;; Additional - ai.example. 3600 IN A 192.0.2.9 - ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B - ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd - hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u - ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy - 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) - ai.example. 3600 AAAA 2001:db8::f00:baa9 - ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK - kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh - 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T - cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 - sZM6QjBBLmukH30+w1z3h8PUP2o= ) - - -B.7 Wildcard No Data Error - - A "NODATA" response for a name covered by a wildcard. The NSEC RRs - prove that the matching wildcard name does not have any RRs of the - requested type and that no closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - - - -Arends, et al. Expires November 15, 2004 [Page 51] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC - *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 - HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU - 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx - 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 - s1InQ2UoIv6tJEaaKkP701j8OLA= ) - - ;; Additional - ;; (empty) - - -B.8 DS Child Zone No Data Error - - A "NODATA" response for a QTYPE=DS query which was mistakenly sent to - a name server for the child zone. - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 52] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - example. IN DS - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - - ;; Additional - ;; (empty) - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 53] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -Appendix C. Authentication Examples - - The examples in this section show how the response messages in - Appendix B are authenticated. - -C.1 Authenticating An Answer - - The query in section Appendix B.1 returned an MX RRset for - "x.w.example.com". The corresponding RRSIG indicates the MX RRset - was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. - The resolver needs the corresponding DNSKEY RR in order to - authenticate this answer. The discussion below describes how a - resolver might obtain this DNSKEY RR. - - The RRSIG indicates the original TTL of the MX RRset was 3600 and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 3 indicates the answer was not - the result of wildcard expansion. The "x.w.example.com" MX RRset is - placed in canonical form and, assuming the current time falls between - the signature inception and expiration dates, the signature is - authenticated. - -C.1.1 Authenticating the example DNSKEY RR - - This example shows the logical authentication process that starts - from the a configured root DNSKEY (or DS RR) and moves down the tree - to authenticate the desired "example" DNSKEY RR. Note the logical - order is presented for clarity and an implementation may choose to - construct the authentication as referrals are received or may choose - to construct the authentication chain only after all RRsets have been - obtained, or in any other combination it sees fit. The example here - demonstrates only the logical process and does not dictate any - implementation rules. - - We assume the resolver starts with an configured DNSKEY RR for the - root zone (or a configured DS RR for the root zone). The resolver - checks this configured DNSKEY RR is present in the root DNSKEY RRset - (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this - DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the DNSKEY - RRset are considered authenticated. The resolver then uses one (or - more) of the root DNSKEY RRs to authenticate the "example" DS RRset. - Note the resolver may need to query the root zone to obtain the root - DNSKEY RRset or "example" DS RRset. - - Once the DS RRset has been authenticated using the root DNSKEY, the - resolver checks the "example" DNSKEY RRset for some "example" DNSKEY - RR that matches one of the authenticated "example" DS RRs. If such a - - - -Arends, et al. Expires November 15, 2004 [Page 54] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - matching "example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the "example" - DNSKEY RRset are considered authenticated. - - Finally the resolver checks that some DNSKEY RR in the "example" - DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY - is used to authenticated the RRSIG included in the response. If - multiple "example" DNSKEY RRs match this algorithm and key tag, then - each DNSKEY RR is tried and the answer is authenticated if any of the - matching DNSKEY RRs validates the signature as described above. - -C.2 Name Error - - The query in section Appendix B.2 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. The NSEC RRs are - authenticated in a manner identical to that of the MX RRset discussed - above. - -C.3 No Data Error - - The query in section Appendix B.3 returned an NSEC RR that proves the - requested name exists, but the requested RR type does not exist. The - negative reply is authenticated by verifying the NSEC RR. The NSEC - RR is authenticated in a manner identical to that of the MX RRset - discussed above. - -C.4 Referral to Signed Zone - - The query in section Appendix B.4 returned a referral to the signed - "a.example." zone. The DS RR is authenticated in a manner identical - to that of the MX RRset discussed above. This DS RR is used to - authenticate the "a.example" DNSKEY RRset. - - Once the "a.example" DS RRset has been authenticated using the - "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset - for some "a.example" DNSKEY RR that matches the DS RR. If such a - matching "a.example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "a.example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the - "a.example" DNSKEY RRset are considered authenticated. - -C.5 Referral to Unsigned Zone - - The query in section Appendix B.5 returned a referral to an unsigned - "b.example." zone. The NSEC proves that no authentication leads from - "example" to "b.example" and the NSEC RR is authenticated in a manner - - - -Arends, et al. Expires November 15, 2004 [Page 55] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - identical to that of the MX RRset discussed above. - -C.6 Wildcard Expansion - - The query in section Appendix B.6 returned an answer that was - produced as a result of wildcard expansion. The RRset expanded as the - similar to The corresponding RRSIG indicates the MX RRset was signed - by an "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG - indicates the original TTL of the MX RRset was 3600 and, for the - purpose of authentication, the current TTL is replaced by 3600. The - RRSIG labels field value of 2 indicates the answer the result of - wildcard expansion since the "a.z.w.example" name contains 4 labels. - The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset - is placed in canonical form and, assuming the current time falls - between the signature inception and expiration dates, the signature - is authenticated. - - The NSEC proves that no closer match (exact or closer wildcard) could - have been used to answer this query and the NSEC RR must also be - authenticated before the answer is considered valid. - -C.7 Wildcard No Data Error - - The query in section Appendix B.7 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. - -C.8 DS Child Zone No Data Error - - The query in section Appendix B.8 returned NSEC RRs that shows the - requested was answered by a child server ("example" server). The - NSEC RR indicates the presence of an SOA RR, showing the answer is - from the child . Queries for the "example" DS RRset should be sent - to the parent servers ("root" servers). - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 56] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires November 15, 2004 [Page 57] - -Internet-Draft DNSSEC Protocol Modifications May 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 58] - - + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: January 13, 2005 M. Larson + VeriSign + R. Austein + ISC + D. Massey + USC/ISI + S. Rose + NIST + July 15, 2004 + + + Protocol Modifications for the DNS Security Extensions + draft-ietf-dnsext-dnssec-protocol-07 + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 13, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document is part of a family of documents which describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + + + +Arends, et al. Expires January 13, 2005 [Page 1] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + collection of new resource records and protocol modifications which + add data origin authentication and data integrity to the DNS. This + document describes the DNSSEC protocol modifications. This document + defines the concept of a signed zone, along with the requirements for + serving and resolving using DNSSEC. These techniques allow a + security-aware resolver to authenticate both DNS resource records and + authoritative DNS error indications. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5 + 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5 + 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6 + 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7 + 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 7 + 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8 + 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10 + 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10 + 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11 + 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11 + 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14 + 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15 + 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16 + 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 + 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17 + 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17 + 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18 + 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.2 Signature Verification Support . . . . . . . . . . . . . . 19 + 4.3 Determining Security Status of Data . . . . . . . . . . . 20 + 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 20 + 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21 + 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22 + 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22 + 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23 + 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23 + 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23 + + + +Arends, et al. Expires January 13, 2005 [Page 2] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23 + 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 + 5.1 Special Considerations for Islands of Security . . . . . . 26 + 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26 + 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27 + 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 + 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 + 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 + 5.3.4 Authenticating A Wildcard Expanded RRset Positive + Response . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 + 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 + 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 + B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 + B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 + B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 + B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 + B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 + B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 + B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 + B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52 + C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54 + C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54 + C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54 + C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55 + C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55 + C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55 + C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55 + C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 + C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 + C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 + Intellectual Property and Copyright Statements . . . . . . . . 57 + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 3] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) are a collection of new resource + records and protocol modifications which add data origin + authentication and data integrity to the DNS. This document defines + the DNSSEC protocol modifications. Section 2 of this document + defines the concept of a signed zone and lists the requirements for + zone signing. Section 3 describes the modifications to authoritative + name server behavior necessary to handle signed zones. Section 4 + describes the behavior of entities which include security-aware + resolver functions. Finally, Section 5 defines how to use DNSSEC RRs + to authenticate a response. + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in [RFC1034] and [RFC1035]. + + This document is part of a family of documents that define DNSSEC. + An introduction to DNSSEC and definition of common terms can be found + in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be + familiar with this document. A definition of the DNSSEC resource + records can be found in [I-D.ietf-dnsext-dnssec-records]. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. [RFC2119]. + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 4] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +2. Zone Signing + + DNSSEC introduces the concept of signed zones. A signed zone + includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to + the rules specified in Section 2.1, Section 2.2, Section 2.3 and + Section 2.4, respectively. A zone that does not include these + records according to the rules in this section is an unsigned zone. + + DNSSEC requires a change to the definition of the CNAME resource + record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG + and NSEC RRs to appear at the same owner name as a CNAME RR. + + DNSSEC specifies the placement of two new RR types, NSEC and DS, + which can be placed at the parental side of a zone cut (that is, at a + delegation point). This is an exception to the general prohibition + against putting data in the parent zone at a zone cut. Section 2.6 + describes this change. + +2.1 Including DNSKEY RRs in a Zone + + To sign a zone, the zone's administrator generates one or more + public/private key pairs and uses the private key(s) to sign + authoritative RRsets in the zone. For each private key used to + create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR + containing the corresponding public key. A zone key DNSKEY RR MUST + have the Zone Key bit of the flags RDATA field set -- see Section + 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys associated + with other DNS operations MAY be stored in DNSKEY RRs that are not + marked as zone keys but MUST NOT be used to verify RRSIGs. + + If the zone administrator intends a signed zone to be usable other + than as an island of security, the zone apex MUST contain at least + one DNSKEY RR to act as a secure entry point into the zone. This + secure entry point could then be used as the target of a secure + delegation via a corresponding DS RR in the parent zone (see + [I-D.ietf-dnsext-dnssec-records]). + +2.2 Including RRSIG RRs in a Zone + + For each authoritative RRset in a signed zone, there MUST be at least + one RRSIG record that meets all of the following requirements: + o The RRSIG owner name is equal to the RRset owner name; + o The RRSIG class is equal to the RRset class; + o The RRSIG Type Covered field is equal to the RRset type; + o The RRSIG Original TTL field is equal to the TTL of the RRset; + o The RRSIG RR's TTL is equal to the TTL of the RRset; + o The RRSIG Labels field is equal to the number of labels in the + RRset owner name, not counting the null root label and not + + + +Arends, et al. Expires January 13, 2005 [Page 5] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + counting the leftmost label if it is a wildcard; + o The RRSIG Signer's Name field is equal to the name of the zone + containing the RRset; and + o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a + zone key DNSKEY record at the zone apex. + + The process for constructing the RRSIG RR for a given RRset is + described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have + multiple RRSIG RRs associated with it. + + An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR + would add no value and would create an infinite loop in the signing + process. + + The NS RRset that appears at the zone apex name MUST be signed, but + the NS RRsets that appear at delegation points (that is, the NS + RRsets in the parent zone that delegate the name to the child zone's + name servers) MUST NOT be signed. Glue address RRsets associated + with delegations MUST NOT be signed. + + There MUST be an RRSIG for each RRset using at least one DNSKEY of + each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset + itself MUST be signed by each algorithm appearing in the DS RRset + located at the delegating parent (if any). + +2.3 Including NSEC RRs in a Zone + + Each owner name in the zone which has authoritative data or a + delegation point NS RRset MUST have an NSEC resource record. The + format of NSEC RRs and the process for constructing the NSEC RR for a + given name is described in [I-D.ietf-dnsext-dnssec-records]. + + The TTL value for any NSEC RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + An NSEC record (and its associated RRSIG RRset) MUST NOT be the only + RRset at any particular owner name. That is, the signing process + MUST NOT create NSEC or RRSIG RRs for owner names nodes which were + not the owner name of any RRset before the zone was signed. The main + reasons for this are a desire for namespace consistency between + signed and unsigned versions of the same zone and a desire to reduce + the risk of response inconsistency in security oblivious recursive + name servers. + + The type bitmap of every NSEC resource record in a signed zone MUST + indicate the presence of both the NSEC record itself and its + corresponding RRSIG record. + + + + +Arends, et al. Expires January 13, 2005 [Page 6] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + The difference between the set of owner names that require RRSIG + records and the set of owner names that require NSEC records is + subtle and worth highlighting. RRSIG records are present at the + owner names of all authoritative RRsets. NSEC records are present at + the owner names of all names for which the signed zone is + authoritative and also at the owner names of delegations from the + signed zone to its children. Neither NSEC nor RRSIG records are + present (in the parent zone) at the owner names of glue address + RRsets. Note, however, that this distinction is for the most part is + only visible during the zone signing process, because NSEC RRsets are + authoritative data, and are therefore signed, thus any owner name + which has an NSEC RRset will have RRSIG RRs as well in the signed + zone. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and any + RRsets for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + +2.4 Including DS RRs in a Zone + + The DS resource record establishes authentication chains between DNS + zones. A DS RRset SHOULD be present at a delegation point when the + child zone is signed. The DS RRset MAY contain multiple records, + each referencing a public key in the child zone used to verify the + RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS + RRsets MUST NOT appear at a zone's apex. + + A DS RR SHOULD point to a DNSKEY RR which is present in the child's + apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed + by the corresponding private key. + + The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset + (that is, the NS RRset from the same zone containing the DS RRset). + + Construction of a DS RR requires knowledge of the corresponding + DNSKEY RR in the child zone, which implies communication between the + child and parent zones. This communication is an operational matter + not covered by this document. + +2.5 Changes to the CNAME Resource Record. + + If a CNAME RRset is present at a name in a signed zone, appropriate + RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that + name for secure dynamic update purposes is also allowed. Other types + MUST NOT be present at that name. + + + + +Arends, et al. Expires January 13, 2005 [Page 7] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + This is a modification to the original CNAME definition given in + [RFC1034]. The original definition of the CNAME RR did not allow any + other types to coexist with a CNAME record, but a signed zone + requires NSEC and RRSIG RRs for every authoritative name. To resolve + this conflict, this specification modifies the definition of the + CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. + +2.6 DNSSEC RR Types Appearing at Zone Cuts. + + DNSSEC introduced two new RR types that are unusual in that they can + appear at the parental side of a zone cut. At the parental side of a + zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at + the owner name. A DS RR could also be present if the zone being + delegated is signed and wishes to have a chain of authentication to + the parent zone. This is an exception to the original DNS + specification ([RFC1034]) which states that only NS RRsets could + appear at the parental side of a zone cut. + + This specification updates the original DNS specification to allow + NSEC and DS RR types at the parent side of a zone cut. These RRsets + are authoritative for the parent when they appear at the parent side + of a zone cut. + +2.7 Example of a Secure Zone + + Appendix A shows a complete example of a small signed zone. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 8] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +3. Serving + + This section describes the behavior of entities that include + security-aware name server functions. In many cases such functions + will be part of a security-aware recursive name server, but a + security-aware authoritative name server has some of the same + requirements. Functions specific to security-aware recursive name + servers are described in Section 3.2; functions specific to + authoritative servers are described in Section 3.1. + + The terms "SNAME", "SCLASS", and "STYPE" in the following discussion + are as used in [RFC1034]. + + A security-aware name server MUST support the EDNS0 [RFC2671] message + size extension, MUST support a message size of at least 1220 octets, + and SHOULD support a message size of 4000 octets [RFC3226]. + + A security-aware name server which receives a DNS query that does not + include the EDNS OPT pseudo-RR or that has the DO bit clear MUST + treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset, + and MUST NOT perform any of the additional processing described + below. Since the DS RR type has the peculiar property of only + existing in the parent zone at delegation points, DS RRs always + require some special processing, as described in Section 3.1.4.1. + + Security aware name servers that receive explicit queries for + security RR types which match the content of more than one zone that + it serves (for example, NSEC and RRSIG RRs above and below a + delegation point where the server is authoritative for both zones) + should behave self-consistently. The name server MAY return one of + the following: + o The above-delegation RRsets + o The below-delegation RRsets + o Both above and below-delegation RRsets + o Empty answer section (no records) + o Some other response + o An error + As long as the response is always consistent for each query to the + name server. + + DNSSEC allocates two new bits in the DNS message header: the CD + (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit + is controlled by resolvers; a security-aware name server MUST copy + the CD bit from a query into the corresponding response. The AD bit + is controlled by name servers; a security-aware name server MUST + ignore the setting of the AD bit in queries. See Section 3.1.6, + Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details + on the behavior of these bits. + + + +Arends, et al. Expires January 13, 2005 [Page 9] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + A security aware name server which synthesizes CNAME RRs from DNAME + RRs as described in [RFC2672] SHOULD NOT generate signatures for the + synthesized CNAME RRs. + +3.1 Authoritative Name Servers + + Upon receiving a relevant query that has the EDNS [RFC2671] OPT + pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name + server for a signed zone MUST include additional RRSIG, NSEC, and DS + RRs according to the following rules: + o RRSIG RRs that can be used to authenticate a response MUST be + included in the response according to the rules in Section 3.1.1; + o NSEC RRs that can be used to provide authenticated denial of + existence MUST be included in the response automatically according + to the rules in Section 3.1.3; + o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST + be included in referrals automatically according to the rules in + Section 3.1.4. + + These rules only apply to responses the semantics of which convey + information about the presence or absence of resource records. That + is, these rules are not intended to rule out responses such as RCODE + 4 ("Not Implemented") or RCODE 5 ("Refused"). + + DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 + discusses zone transfer requirements. + +3.1.1 Including RRSIG RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server SHOULD attempt to send RRSIG RRs that a + security-aware resolver can use to authenticate the RRsets in the + response. A name server SHOULD make every attempt to keep the RRset + and its associated RRSIG(s) together in a response. Inclusion of + RRSIG RRs in a response is subject to the following rules: + o When placing a signed RRset in the Answer section, the name server + MUST also place its RRSIG RRs in the Answer section. The RRSIG + RRs have a higher priority for inclusion than any other RRsets + that may need to be included. If space does not permit inclusion + of these RRSIG RRs, the name server MUST set the TC bit. + o When placing a signed RRset in the Authority section, the name + server MUST also place its RRSIG RRs in the Authority section. + The RRSIG RRs have a higher priority for inclusion than any other + RRsets that may need to be included. If space does not permit + inclusion of these RRSIG RRs, the name server MUST set the TC bit. + o When placing a signed RRset in the Additional section, the name + server MUST also place its RRSIG RRs in the Additional section. + If space does not permit inclusion of both the RRset and its + + + +Arends, et al. Expires January 13, 2005 [Page 10] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If + this happens, the name server MUST NOT set the TC bit solely + because these RRSIG RRs didn't fit. + +3.1.2 Including DNSKEY RRs In a Response + + When responding to a query that has the DO bit set and that requests + the SOA or NS RRs at the apex of a signed zone, a security-aware + authoritative name server for that zone MAY return the zone apex + DNSKEY RRset in the Additional section. In this situation, the + DNSKEY RRset and associated RRSIG RRs have lower priority than any + other information that would be placed in the additional section. + The name server SHOULD NOT include the DNSKEY RRset unless there is + enough space in the response message for both the DNSKEY RRset and + its associated RRSIG RR(s). If there is not enough space to include + these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST + NOT set the TC bit solely because these RRs didn't fit (see Section + 3.1.1). + +3.1.3 Including NSEC RRs In a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server for a signed zone MUST include NSEC RRs in + each of the following cases: + + No Data: The zone contains RRsets that exactly match , + but does not contain any RRsets that exactly match . + + Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match but does contain an RRset that matches + via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match , does contain one or more RRsets that match + via wildcard name expansion, but does not contain + any RRsets that match 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 was + not present in the zone and that the response that the name server is + returning is correct given the data that are in the zone. + + + + + +Arends, et al. Expires January 13, 2005 [Page 11] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +3.1.3.1 Including NSEC RRs: No Data Response + + If the zone contains RRsets matching but contains no + RRset matching , then the name server MUST + include the NSEC RR for 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 + 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 ; and + o An NSEC RR proving that the zone contains no RRsets that would + match 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 but does contain an RRset which matches via wildcard name expansion, the name server MUST include the + wildcard-expanded answer and the corresponding wildcard-expanded + RRSIG RRs in the Answer section, and MUST include in the Authority + + + +Arends, et al. Expires January 13, 2005 [Page 12] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + section an NSEC RR and associated RRSIG RR(s) proving that the zone + does not contain a closer match for . 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 , and while the zone does + contain RRsets which match 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 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 . + + In some cases a single NSEC RR may prove both of these points, in + which case the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + +3.1.3.5 Finding The Right NSEC RRs + + As explained above, there are several situations in which a + security-aware authoritative name server needs to locate an NSEC RR + which proves that no RRsets matching a particular SNAME exist. + Locating such an NSEC RR within an authoritative zone is relatively + simple, at least in concept. The following discussion assumes that + the name server is authoritative for the zone which would have held + the nonexistent RRsets matching SNAME. The algorithm below is + written for clarity, not efficiency. + + To find the NSEC which proves that no RRsets matching name N exist in + the zone Z which would have held them, construct sequence S + consisting of the owner names of every RRset in Z, sorted into + canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate + names. Find the name M which would have immediately preceded N in S + if any RRsets with owner name N had existed. M is the owner name of + the NSEC RR which proves that no RRsets exist with owner name N. + + + +Arends, et al. Expires January 13, 2005 [Page 13] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + The algorithm for finding the NSEC RR which proves that a given name + is not covered by any applicable wildcard is similar, but requires an + extra step. More precisely, the algorithm for finding the NSEC + proving that no RRsets exist with the applicable wildcard name is + precisely the same as the algorithm for finding the NSEC RR which + proves that RRsets with any other owner name do not exist: the part + that's missing is how to determine the name of the nonexistent + applicable wildcard. In practice, this is easy, because the + authoritative name server has already checked for the presence of + precisely this wildcard name as part of step (1)(c) of the normal + lookup algorithm described in Section 4.3.2 of [RFC1034]. + +3.1.4 Including DS RRs In a Response + + When responding to a query which has the DO bit set, a security-aware + authoritative name server returning a referral includes DNSSEC data + along with the NS RRset. + + If a DS RRset is present at the delegation point, the name server + MUST return both the DS RRset and its associated RRSIG RR(s) in the + Authority section along with the NS RRset. The name server MUST + place the NS RRset before the DS RRset and its associated RRSIG + RR(s). + + If no DS RRset is present at the delegation point, the name server + MUST return both the NSEC RR which proves that the DS RRset is not + present and the NSEC RR's associated RRSIG RR(s) along with the NS + RRset. The name server MUST place the NS RRset before the NSEC RRset + and its associated RRSIG RR(s). + + Including these DS, NSEC, and RRSIG RRs increases the size of + referral messages, and may cause some or all glue RRs to be omitted. + If space does not permit inclusion of the DS or NSEC RRset and + associated RRSIG RRs, the name server MUST set the TC bit (see + Section 3.1.1). + +3.1.4.1 Responding to Queries for DS RRs + + The DS resource record type is unusual in that it appears only on the + parent zone's side of a zone cut. For example, the DS RRset for the + delegation of "foo.example" is stored in the "example" zone rather + than in the "foo.example" zone. This requires special processing + rules for both name servers and resolvers, since the name server for + the child zone is authoritative for the name at the zone cut by the + normal DNS rules but the child zone does not contain the DS RRset. + + A security-aware resolver sends queries to the parent zone when + looking for a needed DS RR at a delegation point (see Section 4.2). + + + +Arends, et al. Expires January 13, 2005 [Page 14] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + However, special rules are necessary to avoid confusing + security-oblivious resolvers which might become involved in + processing such a query (for example, in a network configuration that + forces a security-aware resolver to channel its queries through a + security-oblivious recursive name server). The rest of this section + describes how a security-aware name server processes DS queries in + order to avoid this problem. + + The need for special processing by a security-aware name server only + arises when all the following conditions are met: + o the name server has received a query for the DS RRset at a zone + cut; and + o the name server is authoritative for the child zone; and + o the name server is not authoritative for the parent zone; and + o the name server does not offer recursion. + + In all other cases, the name server either has some way of obtaining + the DS RRset or could not have been expected to have the DS RRset + even by the pre-DNSSEC processing rules, so the name server can + return either the DS RRset or an error response according to the + normal processing rules. + + If all of the above conditions are met, however, the name server is + authoritative for SNAME but cannot supply the requested RRset. In + this case, the name server MUST return an authoritative "no data" + response showing that the DS RRset does not exist in the child zone's + apex. See Appendix B.8 for an example of such a response. + +3.1.5 Responding to Queries for Type AXFR or IXFR + + DNSSEC does not change the DNS zone transfer process. A signed zone + will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these + records have no special meaning with respect to a zone transfer + operation. + + An authoritative name server is not required to verify that a zone is + properly signed before sending or accepting a zone transfer. + However, an authoritative name server MAY choose to reject the entire + zone transfer if the zone fails meets any of the signing requirements + described in Section 2. The primary objective of a zone transfer is + to ensure that all authoritative name servers have identical copies + of the zone. An authoritative name server that chooses to perform + its own zone validation MUST NOT selectively reject some RRs and + accept others. + + DS RRsets appear only on the parental side of a zone cut and are + authoritative data in the parent zone. As with any other + authoritative RRset, the DS RRset MUST be included in zone transfers + + + +Arends, et al. Expires January 13, 2005 [Page 15] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + of the zone in which the RRset is authoritative data: in the case of + the DS RRset, this is the parent zone. + + NSEC RRs appear in both the parent and child zones at a zone cut, and + are authoritative data in both the parent and child zones. The + parental and child NSEC RRs at a zone cut are never identical to each + other, since the NSEC RR in the child zone's apex will always + indicate the presence of the child zone's SOA RR while the parental + NSEC RR at the zone cut will never indicate the presence of an SOA + RR. As with any other authoritative RRs, NSEC RRs MUST be included + in zone transfers of the zone in which they are authoritative data: + the parental NSEC RR at a zone cut MUST be included zone transfers of + the parent zone, while the NSEC at the zone apex of the child zone + MUST be included in zone transfers of the child zone. + + RRSIG RRs appear in both the parent and child zones at a zone cut, + and are authoritative in whichever zone contains the authoritative + RRset for which the RRSIG RR provides the signature. That is, the + RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be + authoritative in the parent zone, while the RRSIG for any RRset in + the child zone's apex will be authoritative in the child zone. + Parental and child RRSIG RRs at a zone cut will never be identical to + each other, since the Signer's Name field of an RRSIG RR in the child + zone's apex will indicate a DNSKEY RR in the child zone's apex while + the same field of a parental RRSIG RR at the zone cut will indicate a + DNSKEY RR in the parent zone's apex. As with any other authoritative + RRs, RRSIG RRs MUST be included in zone transfers of the zone in + which they are authoritative data. + +3.1.6 The AD and CD Bits in an Authoritative Response + + The CD and AD bits are designed for use in communication between + security-aware resolvers and security-aware recursive name servers. + These bits are for the most part not relevant to query processing by + security-aware authoritative name servers. + + A security-aware name server does not perform signature validation + for authoritative data during query processing even when the CD bit + is clear. A security-aware name server SHOULD clear the CD bit when + composing an authoritative response. + + A security-aware name server MUST NOT set the AD bit in a response + unless the name server considers all RRsets in the Answer and + Authority sections of the response to be authentic. A security-aware + name server's local policy MAY consider data from an authoritative + zone to be authentic without further validation, but the name server + MUST NOT do so unless the name server obtained the authoritative zone + via secure means (such as a secure zone transfer mechanism), and MUST + + + +Arends, et al. Expires January 13, 2005 [Page 16] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + NOT do so unless this behavior has been configured explicitly. + + A security-aware name server which supports recursion MUST follow the + rules for the CD and AD bits given in Section 3.2 when generating a + response that involves data obtained via recursion. + +3.2 Recursive Name Servers + + As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware + recursive name server is an entity which acts in both the + security-aware name server and security-aware resolver roles. This + section uses the terms "name server side" and "resolver side" to + refer to the code within a security-aware recursive name server which + implements the security-aware name server role and the code which + implements the security-aware resolver role, respectively. + + The resolver side follows the usual rules for caching and negative + caching which would apply to any security-aware resolver. + +3.2.1 The DO bit + + The resolver side of a security-aware recursive name server MUST set + the DO bit when sending requests, regardless of the state of the DO + bit in the initiating request received by the name server side. If + the DO bit in an initiating query is not set, the name server side + MUST strip any authenticating DNSSEC RRs from the response, but MUST + NOT strip any DNSSEC RR types that the initiating query explicitly + requested. + +3.2.2 The CD bit + + The CD bit exists in order to allow a security-aware resolver to + disable signature validation in a security-aware name server's + processing of a particular query. + + The name server side MUST copy the setting of the CD bit from a query + to the corresponding response. + + The name server side of a security-aware recursive name server MUST + pass the sense of the CD bit to the resolver side along with the rest + of an initiating query, so that the resolver side will know whether + or not it is required to verify the response data it returns to the + name server side. If the CD bit is set, it indicates that the + originating resolver is willing to perform whatever authentication + its local policy requires, thus the resolver side of the recursive + name server need not perform authentication on the RRsets in the + response. When the CD bit is set the recursive name server SHOULD, + if possible, return the requested data to the originating resolver + + + +Arends, et al. Expires January 13, 2005 [Page 17] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + even if the recursive name server's local authentication policy would + reject the records in question. That is, by setting the CD bit, the + originating resolver has indicated that it takes responsibility for + performing its own authentication, and the recursive name server + should not interfere. + + If the resolver side implements a BAD cache (see Section 4.7) and the + name server side receives a query which matches an entry in the + resolver side's BAD cache, the name server side's response depends on + the sense of the CD bit in the original query. If the CD bit is set, + the name server side SHOULD return the data from the BAD cache; if + the CD bit is not set, the name server side MUST return RCODE 2 + (server failure). + + The intent of the above rule is to provide the raw data to clients + which are capable of performing their own signature verification + checks while protecting clients which depend on the resolver side of + a security-aware recursive name server to perform such checks. + Several of the possible reasons why signature validation might fail + involve conditions which may not apply equally to the recursive name + server and the client which invoked it: for example, the recursive + name server's clock may be set incorrectly, or the client may have + knowledge of a relevant island of security which the recursive name + server does not share. In such cases, "protecting" a client which is + capable of performing its own signature validation from ever seeing + the "bad" data does not help the client. + +3.2.3 The AD bit + + The name server side of a security-aware recursive name server MUST + NOT set the AD bit in a response unless the name server considers all + RRsets in the Answer and Authority sections of the response to be + authentic. The name server side SHOULD set the AD bit if and only if + the resolver side considers all RRsets in the Answer section and any + relevant negative response RRs in the Authority section to be + authentic. The resolver side MUST follow the procedure described in + Section 5 to determine whether the RRs in question are authentic. + However, for backwards compatibility, a recursive name server MAY set + the AD bit when a response includes unsigned CNAME RRs if those CNAME + RRs demonstrably could have been synthesized from an authentic DNAME + RR which is also included in the response according to the synthesis + rules described in [RFC2672]. + +3.3 Example DNSSEC Responses + + See Appendix B for example response packets. + + + + + +Arends, et al. Expires January 13, 2005 [Page 18] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +4. Resolving + + This section describes the behavior of entities that include + security-aware resolver functions. In many cases such functions will + be part of a security-aware recursive name server, but a stand-alone + security-aware resolver has many of the same requirements. Functions + specific to security-aware recursive name servers are described in + Section 3.2. + +4.1 EDNS Support + + A security-aware resolver MUST include an EDNS [RFC2671] OPT + pseudo-RR with the DO [RFC3225] bit set when sending queries. + + A security-aware resolver MUST support a message size of at least + 1220 octets, SHOULD support a message size of 4000 octets, and MUST + advertise the supported message size using the "sender's UDP payload + size" field in the EDNS OPT pseudo-RR. A security-aware resolver + MUST handle fragmented UDP packets correctly regardless of whether + any such fragmented packets were received via IPv4 or IPv6. Please + see [RFC3226] for discussion of these requirements. + +4.2 Signature Verification Support + + A security-aware resolver MUST support the signature verification + mechanisms described in Section 5, and SHOULD apply them to every + received response except when: + o The security-aware resolver is part of a security-aware recursive + name server, and the response is the result of recursion on behalf + of a query received with the CD bit set; + o The response is the result of a query generated directly via some + form of application interface which instructed the security-aware + resolver not to perform validation for this query; or + o Validation for this query has been disabled by local policy. + + A security-aware resolver's support for signature verification MUST + include support for verification of wildcard owner names. + + Security aware resolvers MAY query for missing security RRs in an + attempt to perform validation; implementations that choose to do so + must be aware that the answers received may not be sufficient to + validate the original response. + + When attempting to retrieve missing NSEC RRs which reside on the + parental side at a zone cut, a security-aware iterative-mode resolver + MUST query the name servers for the parent zone, not the child zone. + + When attempting to retrieve a missing DS, a security-aware + + + +Arends, et al. Expires January 13, 2005 [Page 19] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + iterative-mode resolver MUST query the name servers for the parent + zone, not the child zone. As explained in Section 3.1.4.1, + security-aware name servers need to apply special processing rules to + handle the DS RR, and in some situations the resolver may also need + to apply special rules to locate the name servers for the parent zone + if the resolver does not already have the parent's NS RRset. To + locate the parent NS RRset, the resolver can start with the + delegation name, strip off the leftmost label, and query for an NS + RRset by that name; if no NS RRset is present at that name, the + resolver then strips of the leftmost remaining label and retries the + query for that name, repeating this process of walking up the tree + until it either finds the NS RRset or runs out of labels. + +4.3 Determining Security Status of Data + + A security-aware resolver MUST be able to determine whether or not it + should expect a particular RRset to be signed. More precisely, a + security-aware resolver must be able to distinguish between four + cases: + + Secure: An RRset for which the resolver is able to build a chain of + signed DNSKEY and DS RRs from a trusted security anchor to the + RRset. In this case, the RRset should be signed, and is subject + to signature validation as described above. + + Insecure: An RRset for which the resolver knows that it has no chain + of signed DNSKEY and DS RRs from any trusted starting point to the + RRset. This can occur when the target RRset lies in an unsigned + zone or in a descendent of an unsigned zone. In this case, the + RRset may or may not be signed, but the resolver will not be able + to verify the signature. + + Bogus: An RRset for which the resolver believes that it ought to be + able to establish a chain of trust but is unable to do so, either + due to signatures that for some reason fail to validate or due to + missing data which the relevant DNSSEC RRs indicate should be + present. This case may indicate an attack, but may also indicate + a configuration error or some form of data corruption. + + Indeterminate: An RRset for which the resolver is not able to + determine whether or not the RRset should be signed, because the + resolver is not able to obtain the necessary DNSSEC RRs. This can + occur when the security-aware resolver is not able to contact + security-aware name servers for the relevant zones. + +4.4 Configured Trust Anchors + + A security-aware resolver MUST be capable of being configured with at + + + +Arends, et al. Expires January 13, 2005 [Page 20] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + least one trusted public key or DS RR, and SHOULD be capable of being + configured with multiple trusted public keys or DS RRs. Since a + security-aware resolver will not be able to validate signatures + without such a configured trust anchor, the resolver SHOULD have some + reasonably robust mechanism for obtaining such keys when it boots; + examples of such a mechanism would be some form of non-volatile + storage (such as a disk drive) or some form of trusted local network + configuration mechanism. + + Note that trust anchors also covers key material that is updated in a + secure manner. This secure manner could be through physical media, a + key exchange protocol, or some other out of band means. + +4.5 Response Caching + + A security-aware resolver SHOULD cache each response as a single + atomic entry containing the entire answer, including the named RRset + and any associated DNSSEC RRs. The resolver SHOULD discard the + entire atomic entry when any of the RRs contained in it expire. In + most cases the appropriate cache index for the atomic entry will be + the triple , but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double . + + The reason for these recommendations is that, between the initial + query and the expiration of the data from the cache, the + authoritative data might have been changed (for example, via dynamic + update). + + There are two situations for which this is relevant: + 1. By using the RRSIG record, it is possible to deduce that an + answer was synthesized from a wildcard. A security aware + recursive name server could store this wildcard data and use it + to generate positive responses to queries other than the name for + which the original answer was first received. + 2. NSEC RRs received to prove the non-existence of a name could be + reused by a security aware resolver to prove the non-existence of + any name in the name range it spans. + + In theory, a resolver could use wildcards or NSEC RRs to generate + positive and negative responses (respectively) until the TTL or + signatures on the records in question expire. However, it seems + prudent for resolvers to avoid blocking new authoritative data or + synthesizing new data on their own. Resolvers which follow this + recommendation will have a more consistent view of the namespace. + + + + + + +Arends, et al. Expires January 13, 2005 [Page 21] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +4.6 Handling of the CD and AD bits + + A security-aware resolver MAY set a query's CD bit in order to + indicate that the resolver takes responsibility for performing + whatever authentication its local policy requires on the RRsets in + the response. See Section 3.2 for the effect this bit has on the + behavior of security-aware recursive name servers. + + A security-aware resolver MUST clear the AD bit when composing query + messages to protect against buggy name servers which blindly copy + header bits which they do not understand from the query message to + the response message. + + A resolver MUST disregard the meaning of the CD and AD bits in a + response unless the response was obtained using a secure channel or + the resolver was specifically configured to regard the message header + bits without using a secure channel. + +4.7 Caching BAD Data + + While many validation errors will be transient, some are likely to be + more persistent, such as those caused by administrative error + (failure to re-sign a zone, clock skew, and so forth). Since + requerying will not help in these cases, validating resolvers might + generate a significant amount of unnecessary DNS traffic as a result + of repeated queries for RRsets with persistent validation failures. + + To prevent such unnecessary DNS traffic, security-aware resolvers MAY + cache data with invalid signatures, with some restrictions. + Conceptually, caching such data is similar to negative caching + [RFC2308], except that instead of caching a valid negative response, + the resolver is caching the fact that a particular answer failed to + validate. This document refers to a cache of data with invalid + signatures as a "BAD cache". + + Resolvers which implement a BAD cache MUST take steps to prevent the + cache from being useful as a denial-of-service attack amplifier. In + particular: + o Since RRsets which fail to validate do not have trustworthy TTLs, + the implementation MUST assign a TTL. This TTL SHOULD be small, + in order to mitigate the effect of caching the results of an + attack. + o In order to prevent caching of a transient validation failure + (which might be the result of an attack), resolvers SHOULD track + queries that result in validation failures, and SHOULD only answer + from the BAD cache after the number of times that responses to + queries for that particular have failed to + validate exceeds a threshold value. + + + +Arends, et al. Expires January 13, 2005 [Page 22] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + Resolvers MUST NOT return RRsets from the BAD cache unless the + resolver is not required to validate the signatures of the RRsets in + question under the rules given in Section 4.2 of this document. See + Section 3.2.2 for discussion of how the responses returned by a + security-aware recursive name server interact with a BAD cache. + +4.8 Synthesized CNAMEs + + A validating security-aware resolver MUST treat the signature of a + valid signed DNAME RR as also covering unsigned CNAME RRs which could + have been synthesized from the DNAME RR as described in [RFC2672], at + least to the extent of not rejecting a response message solely + because it contains such CNAME RRs. The resolver MAY retain such + CNAME RRs in its cache or in the answers it hands back, but is not + required to do so. + +4.9 Stub resolvers + + A security-aware stub resolver MUST support the DNSSEC RR types, at + least to the extent of not mishandling responses just because they + contain DNSSEC RRs. + +4.9.1 Handling of the DO Bit + + A non-validating security-aware stub resolver MAY include the DNSSEC + RRs returned by a security-aware recursive name server as part of the + data that the stub resolver hands back to the application which + invoked it but is not required to do so. A non-validating stub + resolver that wishes to do this will need to set the DO bit in + receive DNSSEC RRs from the recursive name server. + + A validating security-aware stub resolver MUST set the DO bit, since + otherwise it will not receive the DNSSEC RRs it needs to perform + signature validation. + +4.9.2 Handling of the CD Bit + + A non-validating security-aware stub resolver SHOULD NOT set the CD + bit when sending queries unless requested by the application layer, + since by definition, a non-validating stub resolver depends on the + security-aware recursive name server to perform validation on its + behalf. + + A validating security-aware stub resolver SHOULD set the CD bit, + since otherwise the security-aware recursive name server will answer + the query using the name server's local policy, which may prevent the + stub resolver from receiving data which would be acceptable to the + stub resolver's local policy. + + + +Arends, et al. Expires January 13, 2005 [Page 23] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +4.9.3 Handling of the AD Bit + + A non-validating security-aware stub resolver MAY chose to examine + the setting of the AD bit in response messages that it receives in + order to determine whether the security-aware recursive name server + which sent the response claims to have cryptographically verified the + data in the Answer and Authority sections of the response message. + Note, however, that the responses received by a security-aware stub + resolver are heavily dependent on the local policy of the + security-aware recursive name server, so as a practical matter there + may be little practical value to checking the status of the AD bit + except perhaps as a debugging aid. In any case, a security-aware + stub resolver MUST NOT place any reliance on signature validation + allegedly performed on its behalf except when the security-aware stub + resolver obtained the data in question from a trusted security-aware + recursive name server via a secure channel. + + A validating security-aware stub resolver SHOULD NOT examine the + setting of the AD bit in response messages, since, by definition, the + stub resolver performs its own signature validation regardless of the + setting of the AD bit. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 24] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +5. Authenticating DNS Responses + + In order to use DNSSEC RRs for authentication, a security-aware + resolver requires configured knowledge of at least one authenticated + DNSKEY or DS RR. The process for obtaining and authenticating this + initial trust anchors is achieved via some external mechanism. For + example, a resolver could use some off-line authenticated exchange to + obtain a zone's DNSKEY RR or obtain a DS RR that identifies and + authenticates a zone's DNSKEY RR. The remainder of this section + assumes that the resolver has somehow obtained an initial set of + trust anchors. + + An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY + RRset. To authenticate an apex DNSKEY RRset using an initial key, + the resolver MUST: + 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag + (DNSKEY RDATA bit 7) set. + 2. Verify that there is some RRSIG RR that covers the apex DNSKEY + RRset, and that the combination of the RRSIG RR and the initial + DNSKEY RR authenticates the DNSKEY RRset. The process for using + an RRSIG RR to authenticate an RRset is described in Section 5.3. + + Once the resolver has authenticated the apex DNSKEY RRset using an + initial DNSKEY RR, delegations from that zone can be authenticated + using DS RRs. This allows a resolver to start from an initial key, + and use DS RRsets to proceed recursively down the DNS tree obtaining + other apex DNSKEY RRsets. If the resolver were configured with a + root DNSKEY RR, and if every delegation had a DS RR associated with + it, then the resolver could obtain and validate any apex DNSKEY + RRset. The process of using DS RRs to authenticate referrals is + described in Section 5.2. + + Once the resolver has authenticated a zone's apex DNSKEY RRset, + Section 5.3 shows how the resolver can use DNSKEY RRs in the apex + DNSKEY RRset and RRSIG RRs from the zone to authenticate any other + RRsets in the zone. Section 5.4 shows how the resolver can use + authenticated NSEC RRsets from the zone to prove that an RRset is not + present in the zone. + + When a resolver indicates support for DNSSEC (by setting the DO bit), + a security-aware name server should attempt to provide the necessary + DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). + However, a security-aware resolver may still receive a response that + that lacks the appropriate DNSSEC RRs, whether due to configuration + issues such as an upstream security-oblivious recursive name server + that accidentally interferes with DNSSEC RRs or due to a deliberate + attack in which an adversary forges a response, strips DNSSEC RRs + + + +Arends, et al. Expires January 13, 2005 [Page 25] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + from a response, or modifies a query so that DNSSEC RRs appear not to + be requested. The absence of DNSSEC data in a response MUST NOT by + itself be taken as an indication that no authentication information + exists. + + A resolver SHOULD expect authentication information from signed + zones. A resolver SHOULD believe that a zone is signed if the + resolver has been configured with public key information for the + zone, or if the zone's parent is signed and the delegation from the + parent contains a DS RRset. + +5.1 Special Considerations for Islands of Security + + Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed + zones for which it is not possible to construct an authentication + chain to the zone from its parent. Validating signatures within an + island of security requires the validator to have some other means of + obtaining an initial authenticated zone key for the island. If a + validator cannot obtain such a key, it SHOULD switch to operating as + if the zones in the island of security are unsigned. + + All the normal processes for validating responses apply to islands of + security. The only difference between normal validation and + validation within an island of security is in how the validator + obtains a trust anchor for the authentication chain. + +5.2 Authenticating Referrals + + Once the apex DNSKEY RRset for a signed parent zone has been + authenticated, DS RRsets can be used to authenticate the delegation + to a signed child zone. A DS RR identifies a DNSKEY RR in the child + zone's apex DNSKEY RRset, and contains a cryptographic digest of the + child zone's DNSKEY RR. A strong cryptographic digest algorithm + ensures that an adversary can not easily generate a DNSKEY RR that + matches the digest. Thus, authenticating the digest allows a + resolver to authenticate the matching DNSKEY RR. The resolver can + then use this child DNSKEY RR to authenticate the entire child apex + DNSKEY RRset. + + Given a DS RR for a delegation, the child zone's apex DNSKEY RRset + can be authenticated if all of the following hold: + o The DS RR has been authenticated using some DNSKEY RR in the + parent's apex DNSKEY RRset (see Section 5.3); + o The Algorithm and Key Tag in the DS RR match the Algorithm field + and the key tag of a DNSKEY RR in the child zone's apex DNSKEY + RRset and, when hashed using the digest algorithm specified in the + DS RR's Digest Type field, results in a digest value that matches + the Digest field of the DS RR; and + + + +Arends, et al. Expires January 13, 2005 [Page 26] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + o The matching DNSKEY RR in the child zone has the Zone Flag bit + set, the corresponding private key has signed the child zone's + apex DNSKEY RRset, and the resulting RRSIG RR authenticates the + child zone's apex DNSKEY RRset. + + If the referral from the parent zone did not contain a DS RRset, the + response should have included a signed NSEC RRset proving that no DS + RRset exists for the delegated name (see Section 3.1.4). A + security-aware resolver MUST query the name servers for the parent + zone for the DS RRset if the referral includes neither a DS RRset nor + a NSEC RRset proving that the DS RRset does not exist (see Section + 4). + + If the validator authenticates an NSEC RRset that proves that no DS + RRset is present for this zone, then there is no authentication path + leading from the parent to the child. If the resolver has an initial + DNSKEY or DS RR that belongs to the child zone or to any delegation + below the child zone, this initial DNSKEY or DS RR MAY be used to + re-establish an authentication path. If no such initial DNSKEY or DS + RR exists, the validator can not authenticate RRsets in or below the + child zone. + + If the validator does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + Note that, for a signed delegation, there are two NSEC RRs associated + with the delegated name. One NSEC RR resides in the parent zone, and + can be used to prove whether a DS RRset exists for the delegated + name. The second NSEC RR resides in the child zone, and identifies + which RRsets are present at the apex of the child zone. The parent + NSEC RR and child NSEC RR can always be distinguished, since the SOA + bit will be set in the child NSEC RR and clear in the parent NSEC RR. + A security-aware resolver MUST use the parent NSEC RR when attempting + to prove that a DS RRset does not exist. + + If the resolver does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver will not be able to verify + the authentication path to the child zone. In this case, the + resolver SHOULD treat the child zone as if it were unsigned. + +5.3 Authenticating an RRset Using an RRSIG RR + + A validator can use an RRSIG RR and its corresponding DNSKEY RR to + attempt to authenticate RRsets. The validator first checks the RRSIG + + + +Arends, et al. Expires January 13, 2005 [Page 27] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + RR to verify that it covers the RRset, has a valid time interval, and + identifies a valid DNSKEY RR. The validator then constructs the + canonical form of the signed data by appending the RRSIG RDATA + (excluding the Signature Field) with the canonical form of the + covered RRset. Finally, the validator uses the public key and + signature to authenticate the signed data. Section 5.3.1, Section + 5.3.2, and Section 5.3.3 describe each step in detail. + +5.3.1 Checking the RRSIG RR Validity + + A security-aware resolver can use an RRSIG RR to authenticate an + RRset if all of the following conditions hold: + o The RRSIG RR and the RRset MUST have the same owner name and the + same class; + o The RRSIG RR's Signer's Name field MUST be the name of the zone + that contains the RRset; + o The RRSIG RR's Type Covered field MUST equal the RRset's type; + o The number of labels in the RRset owner name MUST be greater than + or equal to the value in the RRSIG RR's Labels field; + o The validator's notion of the current time MUST be less than or + equal to the time listed in the RRSIG RR's Expiration field; + o The validator's notion of the current time MUST be greater than or + equal to the time listed in the RRSIG RR's Inception field; + o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST + match the owner name, algorithm, and key tag for some DNSKEY RR in + the zone's apex DNSKEY RRset; + o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY + RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) + set. + + It is possible for more than one DNSKEY RR to match the conditions + above. In this case, the validator cannot predetermine which DNSKEY + RR to use to authenticate the signature, MUST try each matching + DNSKEY RR until either the signature is validated or the validator + has run out of matching public keys to try. + + Note that this authentication process is only meaningful if the + validator authenticates the DNSKEY RR before using it to validate + signatures. The matching DNSKEY RR is considered to be authentic if: + o The apex DNSKEY RRset containing the DNSKEY RR is considered + authentic; or + o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, + and the DNSKEY RR either matches an authenticated DS RR from the + parent zone or matches a trust anchor. + +5.3.2 Reconstructing the Signed Data + + Once the RRSIG RR has met the validity requirements described in + + + +Arends, et al. Expires January 13, 2005 [Page 28] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + Section 5.3.1, the validator needs to reconstruct the original signed + data. The original signed data includes RRSIG RDATA (excluding the + Signature field) and the canonical form of the RRset. Aside from + being ordered, the canonical form of the RRset might also differ from + the received RRset due to DNS name compression, decremented TTLs, or + wildcard expansion. The validator should use the following to + reconstruct the original signed data: + + signed_data = RRSIG_RDATA | RR(1) | RR(2)... where + + "|" denotes concatenation + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signature field excluded and the Signer's Name + in canonical form. + + RR(i) = name | type | class | OrigTTL | RDATA length | RDATA + + name is calculated according to the function below + + class is the RRset's class + + type is the RRset type and all RRs in the class + + OrigTTL is the value from the RRSIG Original TTL field + + All names in the RDATA field are in canonical form + + The set of all RR(i) is sorted into canonical order. + + To calculate the name: + let rrsig_labels = the value of the RRSIG Labels field + + let fqdn = RRset's fully qualified domain name in + canonical form + + let fqdn_labels = Label count of the fqdn above. + + if rrsig_labels = fqdn_labels, + name = fqdn + + if rrsig_labels < fqdn_labels, + name = "*." | the rightmost rrsig_label labels of the + fqdn + + if rrsig_labels > fqdn_labels + the RRSIG RR did not pass the necessary validation + checks and MUST NOT be used to authenticate this + + + +Arends, et al. Expires January 13, 2005 [Page 29] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + RRset. + + The canonical forms for names and RRsets are defined in + [I-D.ietf-dnsext-dnssec-records]. + + NSEC RRsets at a delegation boundary require special processing. + There are two distinct NSEC RRsets associated with a signed delegated + name. One NSEC RRset resides in the parent zone, and specifies which + RRset are present at the parent zone. The second NSEC RRset resides + at the child zone, and identifies which RRsets are present at the + apex in the child zone. The parent NSEC RRset and child NSEC RRset + can always be distinguished since only the child NSEC RRs will + specify an SOA RRset exists at the name. When reconstructing the + original NSEC RRset for the delegation from the parent zone, the NSEC + RRs MUST NOT be combined with NSEC RRs from the child zone, and when + reconstructing the original NSEC RRset for the apex of the child + zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent + zone. + + Note also that each of the two NSEC RRsets at a delegation point has + a corresponding RRSIG RR with an owner name matching the delegated + name, and each of these RRSIG RRs is authoritative data associated + with the same zone that contains the corresponding NSEC RRset. If + necessary, a resolver can tell these RRSIG RRs apart by checking the + Signer's Name field. + +5.3.3 Checking the Signature + + Once the resolver has validated the RRSIG RR as described in Section + 5.3.1 and reconstructed the original signed data as described in + Section 5.3.2, the validator can attempt to use the cryptographic + signature to authenticate the signed data, and thus (finally!) + authenticate the RRset. + + The Algorithm field in the RRSIG RR identifies the cryptographic + algorithm used to generate the signature. The signature itself is + contained in the Signature field of the RRSIG RDATA, and the public + key used to verify the signature is contained in the Public Key field + of the matching DNSKEY RR(s) (found in Section 5.3.1). + [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types + and provides pointers to the documents that define each algorithm's + use. + + Note that it is possible for more than one DNSKEY RR to match the + conditions in Section 5.3.1. In this case, the validator can only + determine which DNSKEY RR by trying each matching public key until + the validator either succeeds in validating the signature or runs out + of keys to try. + + + +Arends, et al. Expires January 13, 2005 [Page 30] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + If the Labels field of the RRSIG RR is not equal to the number of + labels in the RRset's fully qualified owner name, then the RRset is + either invalid or the result of wildcard expansion. The resolver + MUST verify that wildcard expansion was applied properly before + considering the RRset to be authentic. Section 5.3.4 describes how + to determine whether a wildcard was applied properly. + + If other RRSIG RRs also cover this RRset, the local resolver security + policy determines whether the resolver also needs to test these RRSIG + RRs, and determines how to resolve conflicts if these RRSIG RRs lead + to differing results. + + If the resolver accepts the RRset as authentic, the validator MUST + set the TTL of the RRSIG RR and each RR in the authenticated RRset to + a value no greater than the minimum of: + o The RRset's TTL as received in the response; + o The RRSIG RR's TTL as received in the response; + o The value in the RRSIG RR's Original TTL field; and + o The difference of the RRSIG RR's Signature Expiration time and the + current time. + +5.3.4 Authenticating A Wildcard Expanded RRset Positive Response + + If the number of labels in an RRset's owner name is greater than the + Labels field of the covering RRSIG RR, then the RRset and its + covering RRSIG RR were created as a result of wildcard expansion. + Once the validator has verified the signature as described in Section + 5.3, it must take additional steps to verify the non-existence of an + exact match or closer wildcard match for the query. Section 5.4 + discusses these steps. + + Note that the response received by the resolver should include all + NSEC RRs needed to authenticate the response (see Section 3.1.3). + +5.4 Authenticated Denial of Existence + + A resolver can use authenticated NSEC RRs to prove that an RRset is + not present in a signed zone. Security-aware name servers should + automatically include any necessary NSEC RRs for signed zones in + their responses to security-aware resolvers. + + Denial of existence is determined by the following rules: + o If the requested RR name matches the owner name of an + authenticated NSEC RR, then the NSEC RR's type bit map field lists + all RR types present at that owner name, and a resolver can prove + that the requested RR type does not exist by checking for the RR + type in the bit map. If the number of labels in an authenticated + NSEC RR's owner name equals the Labels field of the covering RRSIG + + + +Arends, et al. Expires January 13, 2005 [Page 31] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + RR, then the existence of the NSEC RR proves that wildcard + expansion could not have been used to match the request. + o If the requested RR name would appear after an authenticated NSEC + RR's owner name and before the name listed in that NSEC RR's Next + Domain Name field according to the canonical DNS name order + defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with + the requested name exist in the zone. However, it is possible + that a wildcard could be used to match the requested RR owner name + and type, so proving that the requested RRset does not exist also + requires proving that no possible wildcard RRset exists that could + have been used to generate a positive response. + + In addition, security-aware resolvers MUST authenticate the NSEC + RRsets that comprise the non-existence proof as described in Section + 5.3. + + To prove non-existence of an RRset, the resolver must be able to + verify both that the queried RRset does not exist and that no + relevant wildcard RRset exists. Proving this may require more than + one NSEC RRset from the zone. If the complete set of necessary NSEC + RRsets is not present in a response (perhaps due to message + truncation), then a security-aware resolver MUST resend the query in + order to attempt to obtain the full collection of NSEC RRs necessary + to verify non-existence of the requested RRset. As with all DNS + operations, however, the resolver MUST bound the work it puts into + answering any particular query. + + Since a validated NSEC RR proves the existence of both itself and its + corresponding RRSIG RR, a validator MUST ignore the settings of the + NSEC and RRSIG bits in an NSEC RR. + +5.5 Resolver Behavior When Signatures Do Not Validate + + If for whatever reason none of the RRSIGs can be validated, the + response SHOULD be considered BAD. If the validation was being done + to service a recursive query, the name server MUST return RCODE 2 to + the originating client. However, it MUST return the full response if + and only if the original query had the CD bit set. See also Section + 4.7 on caching responses that do not validate. + +5.6 Authentication Example + + Appendix C shows an example the authentication process. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 32] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +6. IANA Considerations + + [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA + considerations introduced by DNSSEC. The additional IANA + considerations discussed in this document: + + [RFC2535] reserved the CD and AD bits in the message header. The + meaning of the AD bit was redefined in [RFC3655] and the meaning of + both the CD and AD bit are restated in this document. No new bits in + the DNS message header are defined in this document. + + [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit + and defined its use. The use is restated but not altered in this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 33] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +7. Security Considerations + + This document describes how the DNS security extensions use public + key cryptography to sign and authenticate DNS resource record sets. + Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general + security considerations related to DNSSEC; see + [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the + DNSSEC resource record types. + + An active attacker who can set the CD bit in a DNS query message or + the AD bit in a DNS response message can use these bits to defeat the + protection which DNSSEC attempts to provide to security-oblivious + recursive-mode resolvers. For this reason, use of these control bits + by a security-aware recursive-mode resolver requires a secure + channel. See Section 3.2.2 and Section 4.9 for further discussion. + + The protocol described in this document attempts to extend the + benefits of DNSSEC to security-oblivious stub resolvers. However, + since recovery from validation failures is likely to be specific to + particular applications, the facilities that DNSSEC provides for stub + resolvers may prove inadequate. Operators of security-aware + recursive name servers will need to pay close attention to the + behavior of the applications which use their services when choosing a + local validation policy; failure to do so could easily result in the + recursive name server accidentally denying service to the clients it + is intended to support. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 34] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +8. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 35] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +9. References + +9.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-10 (work in progress), May + 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Resource Records for DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-08 (work in progress), + May 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + +9.2 Informative References + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "DNSSEC NSEC RDATA Format", + draft-ietf-dnsext-nsec-rdata-06 (work in progress), May + + + +Arends, et al. Expires January 13, 2005 [Page 36] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + 2004. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + +Arends, et al. Expires January 13, 2005 [Page 37] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 38] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +Appendix A. Signed Zone Example + + The following example shows a (small) complete signed zone. + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB + 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE + VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO + 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM + W6OISukd1EQt7a0kygkg+PEDxdI= ) + 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + 3600 DNSKEY 256 3 5 ( + AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV + rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e + k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo + vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI + + + +Arends, et al. Expires January 13, 2005 [Page 39] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== + ) + 3600 DNSKEY 257 3 5 ( + AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl + LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ + syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP + RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT + Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== + ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 9465 example. + ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ + xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ + XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 + hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY + NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z + DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri + bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp + eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk + 7z5OXogYVaFzHKillDt3HRxHIZM= ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + 3600 NSEC ai.example. NS DS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba + U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 + 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I + BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g + sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + + + +Arends, et al. Expires January 13, 2005 [Page 40] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l + e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh + ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 + AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw + FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) + 3600 AAAA 2001:db8::f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG + CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p + P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN + 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL + AhS+JOVfDI/79QtyTI0SaDWcg8U= ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + 3600 NSEC ns1.example. NS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + ns1.example. 3600 IN A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + + + +Arends, et al. Expires January 13, 2005 [Page 41] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + 3600 NSEC ns2.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + ns2.example. 3600 IN A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + 3600 NSEC *.w.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE + VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb + 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH + l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw + Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) + *.w.example. 3600 IN MX 1 ai.example. + 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + 3600 NSEC x.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + x.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + + + +Arends, et al. Expires January 13, 2005 [Page 42] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + 3600 NSEC x.y.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK + vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E + mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI + NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e + IjgiM8PXkBQtxPq37wDKALkyn7Q= ) + x.y.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia + t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj + q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq + GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb + +gLcMZBnHJ326nb/TOOmrqNmQQE= ) + 3600 NSEC xx.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + xx.example. 3600 IN A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 + t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq + BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 + 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ + RgNvuwbioFSEuv2pNlkq0goYxNY= ) + 3600 AAAA 2001:db8::f00:baaa + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + + + +Arends, et al. Expires January 13, 2005 [Page 43] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + 3600 NSEC example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY + 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k + mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi + asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W + GghLahumFIpg4MO3LS/prgzVVWo= ) + + The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA + Flags indicate that each of these DNSKEY RRs is a zone key. One of + these DNSKEY RRs also has the SEP flag set and has been used to sign + the apex DNSKEY RRset; this is the key which should be hashed to + generate a DS record to be inserted into the parent zone. The other + DNSKEY is used to sign all the other RRsets in the zone. + + The zone includes a wildcard entry "*.w.example". Note that the name + "*.w.example" is used in constructing NSEC chains, and that the RRSIG + covering the "*.w.example" MX RRset has a label count of 2. + + The zone also includes two delegations. The delegation to + "b.example" includes an NS RRset, glue address records, and an NSEC + RR; note that only the NSEC RRset is signed. The delegation to + "a.example" provides a DS RR; note that only the NSEC and DS RRsets + are signed. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 44] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1 Answer + + A successful query to an authoritative server. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + xx.example. 3600 AAAA 2001:db8::f00:baaa + xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + + + +Arends, et al. Expires January 13, 2005 [Page 45] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + + +B.2 Name Error + + An authoritative name error. The NSEC RRs prove that the name does + not exist and that no covering wildcard exists. + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + ml.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + + + +Arends, et al. Expires January 13, 2005 [Page 46] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + +B.3 No Data Error + + A "no data" response. The NSEC RR proves that the name exists and + that the requested RR type does not. + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 47] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC + ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + + ;; Additional + ;; (empty) + + +B.4 Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 48] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + + +B.5 Referral to Unsigned Zone + + Referral to an unsigned zone. The NSEC RR proves that no DS RR for + this delegation exists in the parent zone. + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 49] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + + +B.6 Wildcard Expansion + + A successful query which was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC RR proves that no + closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + + ;; Authority + + + +Arends, et al. Expires January 13, 2005 [Page 50] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + + +B.7 Wildcard No Data Error + + A "no data" response for a name covered by a wildcard. The NSEC RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + + + +Arends, et al. Expires January 13, 2005 [Page 51] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC + *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + + ;; Additional + ;; (empty) + + +B.8 DS Child Zone No Data Error + + A "no data" response for a QTYPE=DS query which was mistakenly sent + to a name server for the child zone. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 52] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 53] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +Appendix C. Authentication Examples + + The examples in this section show how the response messages in + Appendix B are authenticated. + +C.1 Authenticating An Answer + + The query in section Appendix B.1 returned an MX RRset for + "x.w.example.com". The corresponding RRSIG indicates the MX RRset + was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. + The resolver needs the corresponding DNSKEY RR in order to + authenticate this answer. The discussion below describes how a + resolver might obtain this DNSKEY RR. + + The RRSIG indicates the original TTL of the MX RRset was 3600 and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 3 indicates the answer was not + the result of wildcard expansion. The "x.w.example.com" MX RRset is + placed in canonical form and, assuming the current time falls between + the signature inception and expiration dates, the signature is + authenticated. + +C.1.1 Authenticating the example DNSKEY RR + + This example shows the logical authentication process that starts + from the a configured root DNSKEY (or DS RR) and moves down the tree + to authenticate the desired "example" DNSKEY RR. Note the logical + order is presented for clarity and an implementation may choose to + construct the authentication as referrals are received or may choose + to construct the authentication chain only after all RRsets have been + obtained, or in any other combination it sees fit. The example here + demonstrates only the logical process and does not dictate any + implementation rules. + + We assume the resolver starts with an configured DNSKEY RR for the + root zone (or a configured DS RR for the root zone). The resolver + checks this configured DNSKEY RR is present in the root DNSKEY RRset + (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this + DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the DNSKEY + RRset are considered authenticated. The resolver then uses one (or + more) of the root DNSKEY RRs to authenticate the "example" DS RRset. + Note the resolver may need to query the root zone to obtain the root + DNSKEY RRset or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + + + +Arends, et al. Expires January 13, 2005 [Page 54] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + matching "example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "example" DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the "example" + DNSKEY RRset are considered authenticated. + + Finally the resolver checks that some DNSKEY RR in the "example" + DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This + DNSKEY is used to authenticated the RRSIG included in the response. + If multiple "example" DNSKEY RRs match this algorithm and key tag, + then each DNSKEY RR is tried and the answer is authenticated if any + of the matching DNSKEY RRs validates the signature as described + above. + +C.2 Name Error + + The query in section Appendix B.2 returned NSEC RRs that prove the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. The NSEC RRs are + authenticated in a manner identical to that of the MX RRset discussed + above. + +C.3 No Data Error + + The query in section Appendix B.3 returned an NSEC RR that proves the + requested name exists, but the requested RR type does not exist. The + negative reply is authenticated by verifying the NSEC RR. The NSEC + RR is authenticated in a manner identical to that of the MX RRset + discussed above. + +C.4 Referral to Signed Zone + + The query in section Appendix B.4 returned a referral to the signed + "a.example." zone. The DS RR is authenticated in a manner identical + to that of the MX RRset discussed above. This DS RR is used to + authenticate the "a.example" DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "a.example" DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the + "a.example" DNSKEY RRset are considered authenticated. + +C.5 Referral to Unsigned Zone + + The query in section Appendix B.5 returned a referral to an unsigned + "b.example." zone. The NSEC proves that no authentication leads from + + + +Arends, et al. Expires January 13, 2005 [Page 55] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + + "example" to "b.example" and the NSEC RR is authenticated in a manner + identical to that of the MX RRset discussed above. + +C.6 Wildcard Expansion + + The query in section Appendix B.6 returned an answer that was + produced as a result of wildcard expansion. The RRset expanded as + the similar to The corresponding RRSIG indicates the MX RRset was + signed by an "example" DNSKEY with algorithm 5 and key tag 38519. + The RRSIG indicates the original TTL of the MX RRset was 3600 and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 2 indicates the answer the + result of wildcard expansion since the "a.z.w.example" name contains + 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", + the MX RRset is placed in canonical form and, assuming the current + time falls between the signature inception and expiration dates, the + signature is authenticated. + + The NSEC proves that no closer match (exact or closer wildcard) could + have been used to answer this query and the NSEC RR must also be + authenticated before the answer is considered valid. + +C.7 Wildcard No Data Error + + The query in section Appendix B.7 returned NSEC RRs that prove the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. + +C.8 DS Child Zone No Data Error + + The query in section Appendix B.8 returned NSEC RRs that shows the + requested was answered by a child server ("example" server). The + NSEC RR indicates the presence of an SOA RR, showing the answer is + from the child . Queries for the "example" DS RRset should be sent + to the parent servers ("root" servers). + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 56] + +Internet-Draft DNSSEC Protocol Modifications July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires January 13, 2005 [Page 57] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt similarity index 74% rename from doc/draft/draft-ietf-dnsext-dnssec-records-08.txt rename to doc/draft/draft-ietf-dnsext-dnssec-records-09.txt index 3ca99bfb72..79a1728435 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt @@ -1,1961 +1,1849 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: November 15, 2004 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - May 17, 2004 - - - Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-08 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 15, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document is part of a family of documents that describes the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of resource records and protocol modifications that - provide source authentication for the DNS. This document defines the - public key (DNSKEY), delegation signer (DS), resource record digital - - - -Arends, et al. Expires November 15, 2004 [Page 1] - -Internet-Draft DNSSEC Resource Records May 2004 - - - signature (RRSIG), and authenticated denial of existence (NSEC) - resource records. The purpose and format of each resource record is - described in detail, and an example of each resource record is given. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Technical Changes or Corrections . . . . . . . . . . . 4 - 1.3.2 Typos and Minor Corrections . . . . . . . . . . . . . 5 - 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 6 - 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 6 - 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 6 - 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 7 - 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 7 - 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 7 - 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 7 - 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 7 - 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 8 - 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 9 - 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 9 - 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 10 - 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 10 - 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 10 - 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 11 - 3.1.5 Signature Expiration and Inception Fields . . . . . . 11 - 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 11 - 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 12 - 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 12 - 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 13 - 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13 - 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 15 - 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 15 - 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 15 - 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 16 - 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 17 - 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 17 - 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 17 - 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 19 - 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 19 - 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 20 - 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 20 - 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 20 - - - -Arends, et al. Expires November 15, 2004 [Page 2] - -Internet-Draft DNSSEC Resource Records May 2004 - - - 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 20 - 5.2 Processing of DS RRs When Validating Responses . . . . . . 20 - 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 21 - 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 21 - 6. Canonical Form and Order of Resource Records . . . . . . . . . 22 - 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 22 - 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 22 - 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 23 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 - 10.2 Informative References . . . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 - A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 30 - A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 30 - A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 30 - A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 31 - B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 32 - B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 33 - Intellectual Property and Copyright Statements . . . . . . . . 34 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 3] - -Internet-Draft DNSSEC Resource Records May 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduce four new DNS resource - record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the - purpose of each resource record (RR), the RR's RDATA format, and its - presentation format (ASCII representation). - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in [RFC1034], [RFC1035] and subsequent RFCs that update - them: [RFC2136], [RFC2181] and [RFC2308]. - - This document is part of a family of documents that define the DNS - security extensions. The DNS security extensions (DNSSEC) are a - collection of resource records and DNS protocol modifications that - add source authentication and data integrity to the Domain Name - System (DNS). An introduction to DNSSEC and definitions of common - terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description - of DNS protocol modifications can be found in - [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC - resource records. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -1.3 Editors' Notes - -1.3.1 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where no RFC that defines the correct behavior, or if there's - more than one applicable RFC and the definitions conflict, please - post the issue to namedroppers. - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - - - - - - -Arends, et al. Expires November 15, 2004 [Page 4] - -Internet-Draft DNSSEC Resource Records May 2004 - - -1.3.2 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to find - the incorrect text quickly. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 5] - -Internet-Draft DNSSEC Resource Records May 2004 - - -2. The DNSKEY Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). The public keys are stored in DNSKEY - resource records and are used in the DNSSEC authentication process - described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its - authoritative RRsets using a private key and stores the corresponding - public key in a DNSKEY RR. A resolver can then use the public key to - authenticate signatures covering the RRsets in the zone. - - The DNSKEY RR is not intended as a record for storing arbitrary - public keys and MUST NOT be used to store certificates or public keys - that do not directly relate to the DNS infrastructure. - - The Type value for the DNSKEY RR type is 48. - - The DNSKEY RR is class independent. - - The DNSKEY RR has no special TTL requirements. - -2.1 DNSKEY RDATA Wire Format - - The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 - octet Protocol Field, a 1 octet Algorithm Field, and the Public Key - Field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Protocol | Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Public Key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -2.1.1 The Flags Field - - Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, - then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner - name MUST be the name of a zone. If bit 7 has value 0, then the - DNSKEY record holds some other type of DNS public key, such as a - public key used by TKEY and MUST NOT be used to verify RRSIGs that - cover RRsets. - - Bit 15 of the Flags field is the Secure Entry Point flag, described - in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a - - - -Arends, et al. Expires November 15, 2004 [Page 6] - -Internet-Draft DNSSEC Resource Records May 2004 - - - key intended for use as a secure entry point. This flag is only - intended to be to a hint to zone signing or debugging software as to - the intended use of this DNSKEY record; validators MUST NOT alter - their behavior during the signature validation process in any way - based on the setting of this bit. This also means a DNSKEY RR with - the SEP bit set would also need the Zone Key flag set in order to - legally be able to generate signatures. A DNSKEY RR with the SEP set - and the Zone Key flag not set is an invalid DNSKEY. - - Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon - creation of the DNSKEY RR, and MUST be ignored upon reception. - -2.1.2 The Protocol Field - - The Protocol Field MUST have value 3 and the DNSKEY RR MUST be - treated as invalid during signature verification if found to be some - value other than 3. - -2.1.3 The Algorithm Field - - The Algorithm field identifies the public key's cryptographic - algorithm and determines the format of the Public Key field. A list - of DNSSEC algorithm types can be found in Appendix A.1 - -2.1.4 The Public Key Field - - The Public Key Field holds the public key material. The format - depends on the algorithm of the key being stored and are described in - separate documents. - -2.1.5 Notes on DNSKEY RDATA Design - - Although the Protocol Field always has value 3, it is retained for - backward compatibility with early versions of the KEY record. - -2.2 The DNSKEY RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Flag field MUST be represented as an unsigned decimal integer - with a value of 0, 256, or 257. - - The Protocol Field MUST be represented as an unsigned decimal integer - with a value of 3. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic as specified in Appendix A.1. - - - - -Arends, et al. Expires November 15, 2004 [Page 7] - -Internet-Draft DNSSEC Resource Records May 2004 - - - The Public Key field MUST be represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see [RFC1521] Section 5.2. - -2.3 DNSKEY RR Example - - The following DNSKEY RR stores a DNS zone key for example.com. - - example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 - Cbl+BBZH4b/0PY1kxkmvHjcZc8no - kfzj31GajIQKY+5CptLr3buXA10h - WqTkF7H6RfoRqXQeogmMHfpftf6z - Mv1LyBUgia7za6ZEzOJBOztyvhjL - 742iU/TpPSEDhm2SNKLijfUppn1U - aNvv4w== ) - - The first four text fields specify the owner name, TTL, Class, and RR - type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in - the Flags field has value 1. Value 3 is the fixed Protocol value. - Value 5 indicates the public key algorithm. Appendix A.1 identifies - algorithm type 5 as RSA/SHA1 and indicates that the format of the - RSA/SHA1 public key field is defined in [RFC3110]. The remaining - text is a Base64 encoding of the public key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 8] - -Internet-Draft DNSSEC Resource Records May 2004 - - -3. The RRSIG Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). Digital signatures are stored in - RRSIG resource records and are used in the DNSSEC authentication - process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator - can use these RRSIG RRs to authenticate RRsets from the zone. The - RRSIG RR MUST only be used to carry verification material (digital - signatures) used to secure DNS operations. - - An RRSIG record contains the signature for an RRset with a particular - name, class, and type. The RRSIG RR specifies a validity interval - for the signature and uses the Algorithm, the Signer's Name, and the - Key Tag to identify the DNSKEY RR containing the public key that a - validator can use to verify the signature. - - Because every authoritative RRset in a zone must be protected by a - digital signature, RRSIG RRs must be present for names containing a - CNAME RR. This is a change to the traditional DNS specification - [RFC1034] that stated that if a CNAME is present for a name, it is - the only type allowed at that name. A RRSIG and NSEC (see Section 4) - MUST exist for the same name as a CNAME resource record in a signed - zone. - - The Type value for the RRSIG RR type is 46. - - The RRSIG RR is class independent. - - An RRSIG RR MUST have the same class as the RRset it covers. - - The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset - it covers. This is an exception to the [RFC2181] rules for TTL - values of individual RRs within a RRset: individual RRSIG with the - same owner name will have different TTL values if the RRsets they - cover have different TTL values. - -3.1 RRSIG RDATA Wire Format - - The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a - 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original - TTL field, a 4 octet Signature Expiration field, a 4 octet Signature - Inception field, a 2 octet Key tag, the Signer's Name field, and the - Signature field. - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 9] - -Internet-Draft DNSSEC Resource Records May 2004 - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type Covered | Algorithm | Labels | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Original TTL | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Expiration | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Inception | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Signature / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 The Type Covered Field - - The Type Covered field identifies the type of the RRset that is - covered by this RRSIG record. - -3.1.2 The Algorithm Number Field - - The Algorithm Number field identifies the cryptographic algorithm - used to create the signature. A list of DNSSEC algorithm types can - be found in Appendix A.1 - -3.1.3 The Labels Field - - The Labels field specifies the number of labels in the original RRSIG - RR owner name. The significance of this field is that a validator - uses it to determine if the answer was synthesized from a wildcard. - If so, it can be used to determine what owner name was used in - generating the signature. - - To validate a signature, the validator needs the original owner name - that was used to create the signature. If the original owner name - contains a wildcard label ("*"), the owner name may have been - expanded by the server during the response process, in which case the - validator will need to reconstruct the original owner name in order - to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] - describes how to use the Labels field to reconstruct the original - owner name. - - - -Arends, et al. Expires November 15, 2004 [Page 10] - -Internet-Draft DNSSEC Resource Records May 2004 - - - The value of the Labels field MUST NOT count either the null (root) - label that terminates the owner name or the wildcard label (if - present). The value of the Labels field MUST be less than or equal - to the number of labels in the RRSIG owner name. For example, - "www.example.com." has a Labels field value of 3, and - "*.example.com." has a Labels field value of 2. Root (".") has a - Labels field value of 0. - - Although the wildcard label is not included in the count stored in - the Labels field of the RRSIG RR, the wildcard label is part of the - RRset's owner name when generating or verifying the signature. - -3.1.4 Original TTL Field - - The Original TTL field specifies the TTL of the covered RRset as it - appears in the authoritative zone. - - The Original TTL field is necessary because a caching resolver - decrements the TTL value of a cached RRset. In order to validate a - signature, a validator requires the original TTL. - [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original - TTL field value to reconstruct the original TTL. - -3.1.5 Signature Expiration and Inception Fields - - The Signature Expiration and Inception fields specify a validity - period for the signature. The RRSIG record MUST NOT be used for - authentication prior to the inception date and MUST NOT be used for - authentication after the expiration date. - - Signature Expiration and Inception field values are in POSIX.1 time - format: a 32-bit unsigned number of seconds elapsed since 1 January - 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The - longest interval which can be expressed by this format without - wrapping is approximately 136 years. An RRSIG RR can have an - Expiration field value which is numerically smaller than the - Inception field value if the expiration field value is near the - 32-bit wrap-around point or if the signature is long lived. Because - of this, all comparisons involving these fields MUST use "Serial - number arithmetic" as defined in [RFC1982]. As a direct consequence, - the values contained in these fields cannot refer to dates more than - 68 years in either the past or the future. - -3.1.6 The Key Tag Field - - The Key Tag field contains the key tag value of the DNSKEY RR that - validates this signature. Appendix B explains how to calculate Key - Tag values. - - - -Arends, et al. Expires November 15, 2004 [Page 11] - -Internet-Draft DNSSEC Resource Records May 2004 - - -3.1.7 The Signer's Name Field - - The Signer's Name field value identifies the owner name of the DNSKEY - RR which a validator should use to validate this signature. The - Signer's Name field MUST contain the name of the zone of the covered - RRset. A sender MUST NOT use DNS name compression on the Signer's - Name field when transmitting a RRSIG RR. - -3.1.8 The Signature Field - - The Signature field contains the cryptographic signature that covers - the RRSIG RDATA (excluding the Signature field) and the RRset - specified by the RRSIG owner name, RRSIG class, and RRSIG Type - Covered field. The format of this field depends on the algorithm in - use and these formats are described in separate companion documents. - -3.1.8.1 Signature Calculation - - A signature covers the RRSIG RDATA (excluding the Signature Field) - and covers the data RRset specified by the RRSIG owner name, RRSIG - class, and RRSIG Type Covered fields. The RRset is in canonical form - (see Section 6) and the set RR(1),...RR(n) is signed as follows: - - signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where - - "|" denotes concatenation; - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signer's Name field in canonical form and - the Signature field excluded; - - RR(i) = owner | type | class | TTL | RDATA length | RDATA - - "owner" is the fully qualified owner name of the RRset in - canonical form (for RRs with wildcard owner names, the - wildcard label is included in the owner name); - - Each RR MUST have the same owner name as the RRSIG RR; - - Each RR MUST have the same class as the RRSIG RR; - - Each RR in the RRset MUST have the RR type listed in the - RRSIG RR's Type Covered field; - - Each RR in the RRset MUST have the TTL listed in the - RRSIG Original TTL Field; - - Any DNS names in the RDATA field of each RR MUST be in - - - -Arends, et al. Expires November 15, 2004 [Page 12] - -Internet-Draft DNSSEC Resource Records May 2004 - - - canonical form; and - - The RRset MUST be sorted in canonical order. - - See Section 6.1 and Section 6.2 for details on canonical name order - and canonical RR form. - -3.2 The RRSIG RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Type Covered field is represented as a RR type mnemonic. When - the mnemonic is not known, the TYPE representation as described in - [RFC3597] (section 5) MUST be used. - - The Algorithm field value MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix - A.1. - - The Labels field value MUST be represented as an unsigned decimal - integer. - - The Original TTL field value MUST be represented as an unsigned - decimal integer. - - The Signature Expiration Time and Inception Time field values MUST be - represented either as seconds since 1 January 1970 00:00:00 UTC or in - the form YYYYMMDDHHmmSS in UTC, where: - YYYY is the year (0000-9999, but see Section 3.1.5); - MM is the month number (01-12); - DD is the day of the month (01-31); - HH is the hour in 24 hours notation (00-23); - mm is the minute (00-59); and - SS is the second (00-59). - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Signer's Name field value MUST be represented as a domain name. - - The Signature field is represented as a Base64 encoding of the - signature. Whitespace is allowed within the Base64 text. See - Section 2.2. - -3.3 RRSIG RR Example - - The following RRSIG RR stores the signature for the A RRset of - host.example.com: - - - - -Arends, et al. Expires November 15, 2004 [Page 13] - -Internet-Draft DNSSEC Resource Records May 2004 - - - host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( - 20030220173103 2642 example.com. - oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr - PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o - B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t - GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG - J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) - - The first four fields specify the owner name, TTL, Class, and RR type - (RRSIG). The "A" represents the Type Covered field. The value 5 - identifies the algorithm used (RSA/SHA1) to create the signature. - The value 3 is the number of Labels in the original owner name. The - value 86400 in the RRSIG RDATA is the Original TTL for the covered A - RRset. 20030322173103 and 20030220173103 are the expiration and - inception dates, respectively. 2642 is the Key Tag, and example.com. - is the Signer's Name. The remaining text is a Base64 encoding of the - signature. - - Note that combination of RRSIG RR owner name, class, and Type Covered - indicate that this RRSIG covers the "host.example.com" A RRset. The - Label value of 3 indicates that no wildcard expansion was used. The - Algorithm, Signer's Name, and Key Tag indicate this signature can be - authenticated using an example.com zone DNSKEY RR whose algorithm is - 5 and key tag is 2642. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 14] - -Internet-Draft DNSSEC Resource Records May 2004 - - -4. The NSEC Resource Record - - The NSEC resource record lists two separate things: the owner name of - the next authoritative RRset in the canonical ordering of the zone, - and the set of RR types present at the NSEC RR's owner name. The - complete set of NSEC RRs in a zone both indicate which authoritative - RRsets exist in a zone and also form a chain of authoritative owner - names in the zone. This information is used to provide authenticated - denial of existence for DNS data, as described in - [I-D.ietf-dnsext-dnssec-protocol]. - - Because every authoritative name in a zone must be part of the NSEC - chain, NSEC RRs must be present for names containing a CNAME RR. - This is a change to the traditional DNS specification [RFC1034] that - stated that if a CNAME is present for a name, it is the only type - allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist - for the same name as a CNAME resource record in a signed zone. - - See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone - signer determines precisely which NSEC RRs it needs to include in a - zone. - - The type value for the NSEC RR is 47. - - The NSEC RR is class independent. - - The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [RFC2308]. - -4.1 NSEC RDATA Wire Format - - The RDATA of the NSEC RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Domain Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -4.1.1 The Next Domain Name Field - - The Next Domain Name field contains the owner name of the next - authoritative owner name in the canonical ordering of the zone; see - Section 6.1 for an explanation of canonical ordering. The value of - the Next Domain Name field in the last NSEC record in the zone is the - - - -Arends, et al. Expires November 15, 2004 [Page 15] - -Internet-Draft DNSSEC Resource Records May 2004 - - - name of the zone apex (the owner name of the zone's SOA RR). - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. - - Owner names of RRsets not authoritative for the given zone (such as - glue records) MUST NOT be listed in the Next Domain Name unless at - least one authoritative RRset exists at the same owner name. - -4.1.2 The Type Bit Maps Field - - The Type Bit Maps field identifies the RRset types which exist at the - NSEC RR's owner name. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that has - at least one active RR type is encoded using a single octet window - number (from 0 to 255), a single octet bitmap length (from 1 to 32) - indicating the number of octets used for the window block's bitmap, - and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC RR RDATA in increasing numerical - order. - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - where "|" denotes concatenation. - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRset of that type is present for the NSEC - RR's owner name. If a bit is set to 0, it indicates that no RRset of - that type is present for the NSEC RR's owner name. - - Bits representing pseudo-types MUST be set to 0, since they do not - appear in zone data. If encountered, they MUST be ignored upon - reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC RR's owner name. Trailing zero octets not specified MUST be - interpreted as zero octets. - - - - -Arends, et al. Expires November 15, 2004 [Page 16] - -Internet-Draft DNSSEC Resource Records May 2004 - - - The bitmap for the NSEC RR at a delegation point requires special - attention. Bits corresponding to the delegation NS RRset and the RR - types for which the parent zone has authoritative data MUST be set to - 1; bits corresponding to any non-NS RRset for which the parent is not - authoritative MUST be set to 0. - - A zone MUST NOT include an NSEC RR for any domain name that only - holds glue records. - -4.1.3 Inclusion of Wildcard Names in NSEC RDATA - - If a wildcard owner name appears in a zone, the wildcard label ("*") - is treated as a literal symbol and is treated the same as any other - owner name for purposes of generating NSEC RRs. Wildcard owner names - appear in the Next Domain Name field without any wildcard expansion. - [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards - on authenticated denial of existence. - -4.2 The NSEC RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - The Type Bit Maps field is represented as a sequence of RR type - mnemonics. When the mnemonic is not known, the TYPE representation - as described in [RFC3597] (section 5) MUST be used. - -4.3 NSEC RR Example - - The following NSEC RR identifies the RRsets associated with - alfa.example.com. and identifies the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NSEC host.example.com. ( - A MX RRSIG NSEC TYPE1234 ) - - The first four text fields specify the name, TTL, Class, and RR type - (NSEC). The entry host.example.com. is the next authoritative name - after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, - and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and - TYPE1234 RRsets associated with the name alfa.example.com. - - The RDATA section of the NSEC RR above would be encoded as: - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 17] - -Internet-Draft DNSSEC Resource Records May 2004 - - - 0x04 'h' 'o' 's' 't' - 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' - 0x03 'c' 'o' 'm' 0x00 - 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 - 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x20 - - Assuming that the validator can authenticate this NSEC record, it - could be used to prove that beta.example.com does not exist, or could - be used to prove there is no AAAA record associated with - alfa.example.com. Authenticated denial of existence is discussed in - [I-D.ietf-dnsext-dnssec-protocol]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 18] - -Internet-Draft DNSSEC Resource Records May 2004 - - -5. The DS Resource Record - - The DS Resource Record refers to a DNSKEY RR and is used in the DNS - DNSKEY authentication process. A DS RR refers to a DNSKEY RR by - storing the key tag, algorithm number, and a digest of the DNSKEY RR. - Note that while the digest should be sufficient to identify the - public key, storing the key tag and key algorithm helps make the - identification process more efficient. By authenticating the DS - record, a resolver can authenticate the DNSKEY RR to which the DS - record points. The key authentication process is described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The DS RR and its corresponding DNSKEY RR have the same owner name, - but they are stored in different locations. The DS RR appears only - on the upper (parental) side of a delegation, and is authoritative - data in the parent zone. For example, the DS RR for "example.com" is - stored in the "com" zone (the parent zone) rather than in the - "example.com" zone (the child zone). The corresponding DNSKEY RR is - stored in the "example.com" zone (the child zone). This simplifies - DNS zone management and zone signing, but introduces special response - processing requirements for the DS RR; these are described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The type number for the DS record is 43. - - The DS resource record is class independent. - - The DS RR has no special TTL requirements. - -5.1 DS RDATA Wire Format - - The RDATA for a DS RR consists of a 2 octet Key Tag field, a one - octet Algorithm field, a one octet Digest Type field, and a Digest - field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | Digest Type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 19] - -Internet-Draft DNSSEC Resource Records May 2004 - - -5.1.1 The Key Tag Field - - The Key Tag field lists the key tag of the DNSKEY RR referred to by - the DS record. - - The Key Tag used by the DS RR is identical to the Key Tag used by - RRSIG RRs. Appendix B describes how to compute a Key Tag. - -5.1.2 The Algorithm Field - - The Algorithm field lists the algorithm number of the DNSKEY RR - referred to by the DS record. - - The algorithm number used by the DS RR is identical to the algorithm - number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm - number types. - -5.1.3 The Digest Type Field - - The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY - RR. The Digest Type field identifies the algorithm used to construct - the digest. Appendix A.2 lists the possible digest algorithm types. - -5.1.4 The Digest Field - - The DS record refers to a DNSKEY RR by including a digest of that - DNSKEY RR. - - The digest is calculated by concatenating the canonical form of the - fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, - and then applying the digest algorithm. - - digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); - - "|" denotes concatenation - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. - - - The size of the digest may vary depending on the digest algorithm and - DNSKEY RR size. As of the time of writing, the only defined digest - algorithm is SHA-1, which produces a 20 octet digest. - -5.2 Processing of DS RRs When Validating Responses - - The DS RR links the authentication chain across zone boundaries, so - the DS RR requires extra care in processing. The DNSKEY RR referred - to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST - - - -Arends, et al. Expires November 15, 2004 [Page 20] - -Internet-Draft DNSSEC Resource Records May 2004 - - - have Flags bit 7 set to value 1. If the DNSKEY flags do not indicate - a DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT - be used in the validation process. - -5.3 The DS RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic specified in Appendix A.1. - - The Digest Type field MUST be represented as an unsigned decimal - integer. - - The Digest MUST be represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is allowed within the hexadecimal - text. - -5.4 DS RR Example - - The following example shows a DNSKEY RR and its corresponding DS RR. - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A - 98631FAD1A292118 ) - - - The first four text fields specify the name, TTL, Class, and RR type - (DS). Value 60485 is the key tag for the corresponding - "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm - used by this "dskey.example.com." DNSKEY RR. The value 1 is the - algorithm used to construct the digest, and the rest of the RDATA - text is the digest in hexadecimal. - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 21] - -Internet-Draft DNSSEC Resource Records May 2004 - - -6. Canonical Form and Order of Resource Records - - This section defines a canonical form for resource records, a - canonical ordering of DNS names, and a canonical ordering of resource - records within an RRset. A canonical name order is required to - construct the NSEC name chain. A canonical RR form and ordering - within an RRset are required to construct and verify RRSIG RRs. - -6.1 Canonical DNS Name Order - - For purposes of DNS security, owner names are ordered by treating - individual labels as unsigned left-justified octet strings. The - absence of a octet sorts before a zero value octet, and upper case - US-ASCII letters are treated as if they were lower case US-ASCII - letters. - - To compute the canonical ordering of a set of DNS names, start by - sorting the names according to their most significant (rightmost) - labels. For names in which the most significant label is identical, - continue sorting according to their next most significant label, and - so forth. - - For example, the following names are sorted in canonical DNS name - order. The most significant label is "example". At this level, - "example" sorts first, followed by names ending in "a.example", then - names ending "z.example". The names within each level are sorted in - the same way. - - example - a.example - yljkjljk.a.example - Z.a.example - zABC.a.EXAMPLE - z.example - \001.z.example - *.z.example - \200.z.example - - -6.2 Canonical RR Form - - For purposes of DNS security, the canonical form of an RR is the wire - format of the RR where: - 1. Every domain name in the RR is fully expanded (no DNS name - compression) and fully qualified; - 2. All uppercase US-ASCII letters in the owner name of the RR are - replaced by the corresponding lowercase US-ASCII letters; - - - - -Arends, et al. Expires November 15, 2004 [Page 22] - -Internet-Draft DNSSEC Resource Records May 2004 - - - 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, - HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, - SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in - the DNS names contained within the RDATA are replaced by the - corresponding lowercase US-ASCII letters; - 4. If the owner name of the RR is a wildcard name, the owner name is - in its original unexpanded form, including the "*" label (no - wildcard substitution); and - 5. The RR's TTL is set to its original value as it appears in the - originating authoritative zone or the Original TTL field of the - covering RRSIG RR. - -6.3 Canonical RR Ordering Within An RRset - - For purposes of DNS security, RRs with the same owner name, class, - and type are sorted by treating the RDATA portion of the canonical - form of each RR as a left-justified unsigned octet sequence where the - absence of an octet sorts before a zero octet. - - [RFC2181] specifies that an RRset is not allowed to contain duplicate - records (multiple RRs with the same owner name, class, type, and - RDATA). Therefore, if an implementation detects duplicate RRs when - putting the RRset in canonical form, the implementation MUST treat - this as a protocol error. If the implementation chooses to handle - this protocol error in the spirit of the robustness principle (being - liberal in what it accepts), the implementation MUST remove all but - one of the duplicate RR(s) for purposes of calculating the canonical - form of the RRset. - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 23] - -Internet-Draft DNSSEC Resource Records May 2004 - - -7. IANA Considerations - - This document introduces no new IANA considerations, because all of - the protocol parameters used in this document have already been - assigned by previous specifications. However, since the evolution of - DNSSEC has been long and somewhat convoluted, this section attempts - to describe the current state of the IANA registries and other - protocol parameters which are (or once were) related to DNSSEC. - - Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA - considerations. - - DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to - the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS - Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, - and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. [RFC3755] - also marked type 30 (NXT) as Obsolete, and restricted use of types - 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction security - protocol described in [RFC2931] and the transaction KEY Resource - Record described in [RFC2930]. - - DNS Security Algorithm Numbers: [RFC2535] created an IANA registry - for DNSSEC Resource Record Algorithm field numbers, and assigned - values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] - altered this registry to include flags for each entry regarding - its use with the DNS security extensions. Each algorithm entry - could refer to an algorithm that can be used for zone signing, - transaction security (see [RFC2931]) or both. Values 6-251 are - available for assignment by IETF standards action. See Appendix A - for a full listing of the DNS Security Algorithm Numbers entries - at the time of writing and their status of use in DNSSEC. - - [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and - assigned value 0 to reserved and value 1 to SHA-1. - - KEY Protocol Values: [RFC2535] created an IANA Registry for KEY - Protocol Values, but [RFC3445] re-assigned all values other than 3 - to reserved and closed this IANA registry. The registry remains - closed, and all KEY and DNSKEY records are required to have - Protocol Octet value of 3. - - Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA - registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, - this registry only contains an assignment for bit 7 (the ZONE bit) - and a reservation for bit 15 for the Secure Entry Point flag (SEP - bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by - IETF Standards Action. - - - - -Arends, et al. Expires November 15, 2004 [Page 24] - -Internet-Draft DNSSEC Resource Records May 2004 - - -8. Security Considerations - - This document describes the format of four DNS resource records used - by the DNS security extensions, and presents an algorithm for - calculating a key tag for a public key. Other than the items - described below, the resource records themselves introduce no - security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] - and [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations related to the use of these records. - - The DS record points to a DNSKEY RR using a cryptographic digest, the - key algorithm type and a key tag. The DS record is intended to - identify an existing DNSKEY RR, but it is theoretically possible for - an attacker to generate a DNSKEY that matches all the DS fields. The - probability of constructing such a matching DNSKEY depends on the - type of digest algorithm in use. The only currently defined digest - algorithm is SHA-1, and the working group believes that constructing - a public key which would match the algorithm, key tag, and SHA-1 - digest given in a DS record would be a sufficiently difficult problem - that such an attack is not a serious threat at this time. - - The key tag is used to help select DNSKEY resource records - efficiently, but it does not uniquely identify a single DNSKEY - resource record. It is possible for two distinct DNSKEY RRs to have - the same owner name, the same algorithm type, and the same key tag. - An implementation which uses only the key tag to select a DNSKEY RR - might select the wrong public key in some circumstances. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 25] - -Internet-Draft DNSSEC Resource Records May 2004 - - -9. Acknowledgments - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 26] - -Internet-Draft DNSSEC Resource Records May 2004 - - -10. References - -10.1 Normative References - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-10 (work in progress), May - 2004. - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in - progress), May 2004. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet - Mail Extensions) Part One: Mechanisms for Specifying and - Describing the Format of Internet Message Bodies", RFC - 1521, September 1993. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - - -Arends, et al. Expires November 15, 2004 [Page 27] - -Internet-Draft DNSSEC Resource Records May 2004 - - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", RFC 3755, April 2004. - - [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", RFC 3757, April 2004. - -10.2 Informative References - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "KEY RR Secure Entry Point Flag", - draft-ietf-dnsext-nsec-rdata-05 (work in progress), March - 2004. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 28] - -Internet-Draft DNSSEC Resource Records May 2004 - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 29] - -Internet-Draft DNSSEC Resource Records May 2004 - - -Appendix A. DNSSEC Algorithm and Digest Types - - The DNS security extensions are designed to be independent of the - underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS - resource records all use a DNSSEC Algorithm Number to identify the - cryptographic algorithm in use by the resource record. The DS - resource record also specifies a Digest Algorithm Number to identify - the digest algorithm used to construct the DS record. The currently - defined Algorithm and Digest Types are listed below. Additional - Algorithm or Digest Types could be added as advances in cryptography - warrant. - - A DNSSEC aware resolver or name server MUST implement all MANDATORY - algorithms. - -A.1 DNSSEC Algorithm Types - - The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify - the security algorithm being used. These values are stored in the - "Algorithm number" field in the resource record RDATA. - - Some algorithms are usable only for zone signing (DNSSEC), some only - for transaction security mechanisms (SIG(0) and TSIG), and some for - both. Those usable for zone signing may appear in DNSKEY, RRSIG, and - DS RRs. Those usable for transaction security would be present in - SIG(0) and KEY RRs as described in [RFC2931] - - Zone - Value Algorithm [Mnemonic] Signing References Status - ----- -------------------- --------- ---------- --------- - 0 reserved - 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED - 2 Diffie-Hellman [DH] n RFC 2539 - - 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL - 4 Elliptic Curve [ECC] TBA - - 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY - 252 Indirect [INDIRECT] n - - 253 Private [PRIVATEDNS] y see below OPTIONAL - 254 Private [PRIVATEOID] y see below OPTIONAL - 255 reserved - - 6 - 251 Available for assignment by IETF Standards Action. - -A.1.1 Private Algorithm Types - - Algorithm number 253 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with a wire encoded - - - -Arends, et al. Expires November 15, 2004 [Page 30] - -Internet-Draft DNSSEC Resource Records May 2004 - - - domain name, which MUST NOT be compressed. The domain name indicates - the private algorithm to use and the remainder of the public key area - is determined by that algorithm. Entities should only use domain - names they control to designate their private algorithms. - - Algorithm number 254 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with an unsigned - length byte followed by a BER encoded Object Identifier (ISO OID) of - that length. The OID indicates the private algorithm in use and the - remainder of the area is whatever is required by that algorithm. - Entities should only use OIDs they control to designate their private - algorithms. - -A.2 DNSSEC Digest Types - - A "Digest Type" field in the DS resource record types identifies the - cryptographic digest algorithm used by the resource record. The - following table lists the currently defined digest algorithm types. - - VALUE Algorithm STATUS - 0 Reserved - - 1 SHA-1 MANDATORY - 2-255 Unassigned - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 31] - -Internet-Draft DNSSEC Resource Records May 2004 - - -Appendix B. Key Tag Calculation - - The Key Tag field in the RRSIG and DS resource record types provides - a mechanism for selecting a public key efficiently. In most cases, a - combination of owner name, algorithm, and key tag can efficiently - identify a DNSKEY record. Both the RRSIG and DS resource records - have corresponding DNSKEY records. The Key Tag field in the RRSIG - and DS records can be used to help select the corresponding DNSKEY RR - efficiently when more than one candidate DNSKEY RR is available. - - However, it is essential to note that the key tag is not a unique - identifier. It is theoretically possible for two distinct DNSKEY RRs - to have the same owner name, the same algorithm, and the same key - tag. The key tag is used to limit the possible candidate keys, but it - does not uniquely identify a DNSKEY record. Implementations MUST NOT - assume that the key tag uniquely identifies a DNSKEY RR. - - The key tag is the same for all DNSKEY algorithm types except - algorithm 1 (please see Appendix B.1 for the definition of the key - tag for algorithm 1). The key tag algorithm is the sum of the wire - format of the DNSKEY RDATA broken into 2 octet groups. First the - RDATA (in wire format) is treated as a series of 2 octet groups, - these groups are then added together ignoring any carry bits. - - A reference implementation of the key tag algorithm is as an ANSI C - function is given below with the RDATA portion of the DNSKEY RR is - used as input. It is not necessary to use the following reference - code verbatim, but the numerical value of the Key Tag MUST be - identical to what the reference implementation would generate for the - same input. - - Please note that the algorithm for calculating the Key Tag is almost - but not completely identical to the familiar ones complement checksum - used in many other Internet protocols. Key Tags MUST be calculated - using the algorithm described here rather than the ones complement - checksum. - - The following ANSI C reference implementation calculates the value of - a Key Tag. This reference implementation applies to all algorithm - types except algorithm 1 (see Appendix B.1). The input is the wire - format of the RDATA portion of the DNSKEY RR. The code is written - for clarity, not efficiency. - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 32] - -Internet-Draft DNSSEC Resource Records May 2004 - - - /* - * Assumes that int is at least 16 bits. - * First octet of the key tag is the most significant 8 bits of the - * return value; - * Second octet of the key tag is the least significant 8 bits of the - * return value. - */ - - unsigned int - keytag ( - unsigned char key[], /* the RDATA part of the DNSKEY RR */ - unsigned int keysize /* the RDLENGTH */ - ) - { - unsigned long ac; /* assumed to be 32 bits or larger */ - int i; /* loop index */ - - for ( ac = 0, i = 0; i < keysize; ++i ) - ac += (i & 1) ? key[i] : key[i] << 8; - ac += (ac >> 16) & 0xFFFF; - return ac & 0xFFFF; - } - - -B.1 Key Tag for Algorithm 1 (RSA/MD5) - - The key tag for algorithm 1 (RSA/MD5) is defined differently than the - key tag for all other algorithms, for historical reasons. For a - DNSKEY RR with algorithm 1, the key tag is defined to be the most - significant 16 bits of the least significant 24 bits in the public - key modulus (in other words, the 4th to last and 3rd to last octets - of the public key modulus). - - Please note that Algorithm 1 is NOT RECOMMENDED. - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 33] - -Internet-Draft DNSSEC Resource Records May 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires November 15, 2004 [Page 34] - -Internet-Draft DNSSEC Resource Records May 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires November 15, 2004 [Page 35] - - + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: January 13, 2005 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + July 15, 2004 + + + Resource Records for the DNS Security Extensions + draft-ietf-dnsext-dnssec-records-09 + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 13, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document is part of a family of documents that describes the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + + + +Arends, et al. Expires January 13, 2005 [Page 1] + +Internet-Draft DNSSEC Resource Records July 2004 + + + collection of resource records and protocol modifications that + provide source authentication for the DNS. This document defines the + public key (DNSKEY), delegation signer (DS), resource record digital + signature (RRSIG), and authenticated denial of existence (NSEC) + resource records. The purpose and format of each resource record is + described in detail, and an example of each resource record is given. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 5 + 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 5 + 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 5 + 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 6 + 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 6 + 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 6 + 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 6 + 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 6 + 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 7 + 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 8 + 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 8 + 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 9 + 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 9 + 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 9 + 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 10 + 3.1.5 Signature Expiration and Inception Fields . . . . . . 10 + 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 10 + 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11 + 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11 + 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12 + 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12 + 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14 + 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14 + 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14 + 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 15 + 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 16 + 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 16 + 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 16 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18 + 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18 + 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 19 + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 19 + 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 19 + + + +Arends, et al. Expires January 13, 2005 [Page 2] + +Internet-Draft DNSSEC Resource Records July 2004 + + + 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 19 + 5.2 Processing of DS RRs When Validating Responses . . . . . . 19 + 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 20 + 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Canonical Form and Order of Resource Records . . . . . . . . . 21 + 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 21 + 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 21 + 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 22 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 + 10.2 Informative References . . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 + A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 29 + A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29 + A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 29 + A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 30 + B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 31 + B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 32 + Intellectual Property and Copyright Statements . . . . . . . . 33 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 3] + +Internet-Draft DNSSEC Resource Records July 2004 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the + purpose of each resource record (RR), the RR's RDATA format, and its + presentation format (ASCII representation). + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035] and subsequent RFCs that update + them: [RFC2136], [RFC2181] and [RFC2308]. + + This document is part of a family of documents that define the DNS + security extensions. The DNS security extensions (DNSSEC) are a + collection of resource records and DNS protocol modifications that + add source authentication and data integrity to the Domain Name + System (DNS). An introduction to DNSSEC and definitions of common + terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is + assumed to be familiar with this document. A description of DNS + protocol modifications can be found in + [I-D.ietf-dnsext-dnssec-protocol]. + + This document defines the DNSSEC resource records. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 4] + +Internet-Draft DNSSEC Resource Records July 2004 + + +2. The DNSKEY Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). The public keys are stored in DNSKEY + resource records and are used in the DNSSEC authentication process + described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its + authoritative RRsets using a private key and stores the corresponding + public key in a DNSKEY RR. A resolver can then use the public key to + authenticate signatures covering the RRsets in the zone. + + The DNSKEY RR is not intended as a record for storing arbitrary + public keys and MUST NOT be used to store certificates or public keys + that do not directly relate to the DNS infrastructure. + + The Type value for the DNSKEY RR type is 48. + + The DNSKEY RR is class independent. + + The DNSKEY RR has no special TTL requirements. + +2.1 DNSKEY RDATA Wire Format + + The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 + octet Protocol Field, a 1 octet Algorithm Field, and the Public Key + Field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Public Key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +2.1.1 The Flags Field + + Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, + then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner + name MUST be the name of a zone. If bit 7 has value 0, then the + DNSKEY record holds some other type of DNS public key and MUST NOT be + used to verify RRSIGs that cover RRsets. + + Bit 15 of the Flags field is the Secure Entry Point flag, described + in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a + key intended for use as a secure entry point. This flag is only + + + +Arends, et al. Expires January 13, 2005 [Page 5] + +Internet-Draft DNSSEC Resource Records July 2004 + + + intended to be to a hint to zone signing or debugging software as to + the intended use of this DNSKEY record; validators MUST NOT alter + their behavior during the signature validation process in any way + based on the setting of this bit. This also means a DNSKEY RR with + the SEP bit set would also need the Zone Key flag set in order to + legally be able to generate signatures. A DNSKEY RR with the SEP set + and the Zone Key flag not set MUST NOT be used to verify RRSIGs that + cover RRsets. + + Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon + creation of the DNSKEY RR, and MUST be ignored upon reception. + +2.1.2 The Protocol Field + + The Protocol Field MUST have value 3 and the DNSKEY RR MUST be + treated as invalid during signature verification if found to be some + value other than 3. + +2.1.3 The Algorithm Field + + The Algorithm field identifies the public key's cryptographic + algorithm and determines the format of the Public Key field. A list + of DNSSEC algorithm types can be found in Appendix A.1 + +2.1.4 The Public Key Field + + The Public Key Field holds the public key material. The format + depends on the algorithm of the key being stored and are described in + separate documents. + +2.1.5 Notes on DNSKEY RDATA Design + + Although the Protocol Field always has value 3, it is retained for + backward compatibility with early versions of the KEY record. + +2.2 The DNSKEY RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Flag field MUST be represented as an unsigned decimal integer. + Given the currently defined flags, the possible values are: 0, 256, + or 257. + + The Protocol Field MUST be represented as an unsigned decimal integer + with a value of 3. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic as specified in Appendix A.1. + + + +Arends, et al. Expires January 13, 2005 [Page 6] + +Internet-Draft DNSSEC Resource Records July 2004 + + + The Public Key field MUST be represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see [RFC3548]. + +2.3 DNSKEY RR Example + + The following DNSKEY RR stores a DNS zone key for example.com. + + example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 + Cbl+BBZH4b/0PY1kxkmvHjcZc8no + kfzj31GajIQKY+5CptLr3buXA10h + WqTkF7H6RfoRqXQeogmMHfpftf6z + Mv1LyBUgia7za6ZEzOJBOztyvhjL + 742iU/TpPSEDhm2SNKLijfUppn1U + aNvv4w== ) + + The first four text fields specify the owner name, TTL, Class, and RR + type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in + the Flags field has value 1. Value 3 is the fixed Protocol value. + Value 5 indicates the public key algorithm. Appendix A.1 identifies + algorithm type 5 as RSA/SHA1 and indicates that the format of the + RSA/SHA1 public key field is defined in [RFC3110]. The remaining + text is a Base64 encoding of the public key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 7] + +Internet-Draft DNSSEC Resource Records July 2004 + + +3. The RRSIG Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). Digital signatures are stored in + RRSIG resource records and are used in the DNSSEC authentication + process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator + can use these RRSIG RRs to authenticate RRsets from the zone. The + RRSIG RR MUST only be used to carry verification material (digital + signatures) used to secure DNS operations. + + An RRSIG record contains the signature for an RRset with a particular + name, class, and type. The RRSIG RR specifies a validity interval + for the signature and uses the Algorithm, the Signer's Name, and the + Key Tag to identify the DNSKEY RR containing the public key that a + validator can use to verify the signature. + + Because every authoritative RRset in a zone must be protected by a + digital signature, RRSIG RRs must be present for names containing a + CNAME RR. This is a change to the traditional DNS specification + [RFC1034] that stated that if a CNAME is present for a name, it is + the only type allowed at that name. A RRSIG and NSEC (see Section 4) + MUST exist for the same name as a CNAME resource record in a signed + zone. + + The Type value for the RRSIG RR type is 46. + + The RRSIG RR is class independent. + + An RRSIG RR MUST have the same class as the RRset it covers. + + The TTL value of an RRSIG RR MUST match the TTL value of the RRset it + covers. This is an exception to the [RFC2181] rules for TTL values + of individual RRs within a RRset: individual RRSIG with the same + owner name will have different TTL values if the RRsets they cover + have different TTL values. + +3.1 RRSIG RDATA Wire Format + + The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a + 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original + TTL field, a 4 octet Signature Expiration field, a 4 octet Signature + Inception field, a 2 octet Key tag, the Signer's Name field, and the + Signature field. + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 8] + +Internet-Draft DNSSEC Resource Records July 2004 + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type Covered | Algorithm | Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 The Type Covered Field + + The Type Covered field identifies the type of the RRset that is + covered by this RRSIG record. + +3.1.2 The Algorithm Number Field + + The Algorithm Number field identifies the cryptographic algorithm + used to create the signature. A list of DNSSEC algorithm types can + be found in Appendix A.1 + +3.1.3 The Labels Field + + The Labels field specifies the number of labels in the original RRSIG + RR owner name. The significance of this field is that a validator + uses it to determine if the answer was synthesized from a wildcard. + If so, it can be used to determine what owner name was used in + generating the signature. + + To validate a signature, the validator needs the original owner name + that was used to create the signature. If the original owner name + contains a wildcard label ("*"), the owner name may have been + expanded by the server during the response process, in which case the + validator will need to reconstruct the original owner name in order + to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] + describes how to use the Labels field to reconstruct the original + owner name. + + + +Arends, et al. Expires January 13, 2005 [Page 9] + +Internet-Draft DNSSEC Resource Records July 2004 + + + The value of the Labels field MUST NOT count either the null (root) + label that terminates the owner name or the wildcard label (if + present). The value of the Labels field MUST be less than or equal + to the number of labels in the RRSIG owner name. For example, + "www.example.com." has a Labels field value of 3, and + "*.example.com." has a Labels field value of 2. Root (".") has a + Labels field value of 0. + + Although the wildcard label is not included in the count stored in + the Labels field of the RRSIG RR, the wildcard label is part of the + RRset's owner name when generating or verifying the signature. + +3.1.4 Original TTL Field + + The Original TTL field specifies the TTL of the covered RRset as it + appears in the authoritative zone. + + The Original TTL field is necessary because a caching resolver + decrements the TTL value of a cached RRset. In order to validate a + signature, a validator requires the original TTL. + [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original + TTL field value to reconstruct the original TTL. + +3.1.5 Signature Expiration and Inception Fields + + The Signature Expiration and Inception fields specify a validity + period for the signature. The RRSIG record MUST NOT be used for + authentication prior to the inception date and MUST NOT be used for + authentication after the expiration date. + + Signature Expiration and Inception field values are in POSIX.1 time + format: a 32-bit unsigned number of seconds elapsed since 1 January + 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The + longest interval which can be expressed by this format without + wrapping is approximately 136 years. An RRSIG RR can have an + Expiration field value which is numerically smaller than the + Inception field value if the expiration field value is near the + 32-bit wrap-around point or if the signature is long lived. Because + of this, all comparisons involving these fields MUST use "Serial + number arithmetic" as defined in [RFC1982]. As a direct consequence, + the values contained in these fields cannot refer to dates more than + 68 years in either the past or the future. + +3.1.6 The Key Tag Field + + The Key Tag field contains the key tag value of the DNSKEY RR that + validates this signature, in network byte order. Appendix B explains + how to calculate Key Tag values. + + + +Arends, et al. Expires January 13, 2005 [Page 10] + +Internet-Draft DNSSEC Resource Records July 2004 + + +3.1.7 The Signer's Name Field + + The Signer's Name field value identifies the owner name of the DNSKEY + RR which a validator is supposed to use to validate this signature. + The Signer's Name field MUST contain the name of the zone of the + covered RRset. A sender MUST NOT use DNS name compression on the + Signer's Name field when transmitting a RRSIG RR. + +3.1.8 The Signature Field + + The Signature field contains the cryptographic signature that covers + the RRSIG RDATA (excluding the Signature field) and the RRset + specified by the RRSIG owner name, RRSIG class, and RRSIG Type + Covered field. The format of this field depends on the algorithm in + use and these formats are described in separate companion documents. + +3.1.8.1 Signature Calculation + + A signature covers the RRSIG RDATA (excluding the Signature Field) + and covers the data RRset specified by the RRSIG owner name, RRSIG + class, and RRSIG Type Covered fields. The RRset is in canonical form + (see Section 6) and the set RR(1),...RR(n) is signed as follows: + + signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where + + "|" denotes concatenation; + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signer's Name field in canonical form and + the Signature field excluded; + + RR(i) = owner | type | class | TTL | RDATA length | RDATA + + "owner" is the fully qualified owner name of the RRset in + canonical form (for RRs with wildcard owner names, the + wildcard label is included in the owner name); + + Each RR MUST have the same owner name as the RRSIG RR; + + Each RR MUST have the same class as the RRSIG RR; + + Each RR in the RRset MUST have the RR type listed in the + RRSIG RR's Type Covered field; + + Each RR in the RRset MUST have the TTL listed in the + RRSIG Original TTL Field; + + Any DNS names in the RDATA field of each RR MUST be in + + + +Arends, et al. Expires January 13, 2005 [Page 11] + +Internet-Draft DNSSEC Resource Records July 2004 + + + canonical form; and + + The RRset MUST be sorted in canonical order. + + See Section 6.2 and Section 6.3 for details on canonical form and + ordering of RRsets. + +3.2 The RRSIG RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Type Covered field is represented as a RR type mnemonic. When + the mnemonic is not known, the TYPE representation as described in + [RFC3597] (section 5) MUST be used. + + The Algorithm field value MUST be represented either as an unsigned + decimal integer or as an algorithm mnemonic as specified in Appendix + A.1. + + The Labels field value MUST be represented as an unsigned decimal + integer. + + The Original TTL field value MUST be represented as an unsigned + decimal integer. + + The Signature Expiration Time and Inception Time field values MUST be + represented either as seconds since 1 January 1970 00:00:00 UTC or in + the form YYYYMMDDHHmmSS in UTC, where: + YYYY is the year (0001-9999, but see Section 3.1.5); + MM is the month number (01-12); + DD is the day of the month (01-31); + HH is the hour in 24 hours notation (00-23); + mm is the minute (00-59); and + SS is the second (00-59). + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Signer's Name field value MUST be represented as a domain name. + + The Signature field is represented as a Base64 encoding of the + signature. Whitespace is allowed within the Base64 text. See + Section 2.2. + +3.3 RRSIG RR Example + + The following RRSIG RR stores the signature for the A RRset of + host.example.com: + + + + +Arends, et al. Expires January 13, 2005 [Page 12] + +Internet-Draft DNSSEC Resource Records July 2004 + + + host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( + 20030220173103 2642 example.com. + oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr + PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o + B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t + GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG + J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) + + The first four fields specify the owner name, TTL, Class, and RR type + (RRSIG). The "A" represents the Type Covered field. The value 5 + identifies the algorithm used (RSA/SHA1) to create the signature. + The value 3 is the number of Labels in the original owner name. The + value 86400 in the RRSIG RDATA is the Original TTL for the covered A + RRset. 20030322173103 and 20030220173103 are the expiration and + inception dates, respectively. 2642 is the Key Tag, and example.com. + is the Signer's Name. The remaining text is a Base64 encoding of the + signature. + + Note that combination of RRSIG RR owner name, class, and Type Covered + indicate that this RRSIG covers the "host.example.com" A RRset. The + Label value of 3 indicates that no wildcard expansion was used. The + Algorithm, Signer's Name, and Key Tag indicate this signature can be + authenticated using an example.com zone DNSKEY RR whose algorithm is + 5 and key tag is 2642. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 13] + +Internet-Draft DNSSEC Resource Records July 2004 + + +4. The NSEC Resource Record + + The NSEC resource record lists two separate things: the next owner + name (in the canonical ordering of the zone) which contains + authoritative data or a delegation point NS RRset, and the set of RR + types present at the NSEC RR's owner name. The complete set of NSEC + RRs in a zone both indicate which authoritative RRsets exist in a + zone and also form a chain of authoritative owner names in the zone. + This information is used to provide authenticated denial of existence + for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol]. + + Because every authoritative name in a zone must be part of the NSEC + chain, NSEC RRs must be present for names containing a CNAME RR. + This is a change to the traditional DNS specification [RFC1034] that + stated that if a CNAME is present for a name, it is the only type + allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist + for the same name as a CNAME resource record in a signed zone. + + See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone + signer determines precisely which NSEC RRs it needs to include in a + zone. + + The type value for the NSEC RR is 47. + + The NSEC RR is class independent. + + The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [RFC2308]. + +4.1 NSEC RDATA Wire Format + + The RDATA of the NSEC RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +4.1.1 The Next Domain Name Field + + The Next Domain field contains the next owner name (in the canonical + ordering of the zone) which has authoritative data or contains a + delegation point NS RRset; see Section 6.1 for an explanation of + canonical ordering. The value of the Next Domain Name field in the + + + +Arends, et al. Expires January 13, 2005 [Page 14] + +Internet-Draft DNSSEC Resource Records July 2004 + + + last NSEC record in the zone is the name of the zone apex (the owner + name of the zone's SOA RR). This indicates that the owner name of + the NSEC RR is the last name in the canonical ordering of the zone. + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. + + Owner names of RRsets not authoritative for the given zone (such as + glue records) MUST NOT be listed in the Next Domain Name unless at + least one authoritative RRset exists at the same owner name. + +4.1.2 The Type Bit Maps Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC RR's owner name. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that + has at least one active RR type is encoded using a single octet + window number (from 0 to 255), a single octet bitmap length (from 1 + to 32) indicating the number of octets used for the window block's + bitmap, and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC RR RDATA in increasing numerical + order. + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + where "|" denotes concatenation. + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set, + it indicates that an RRset of that type is present for the NSEC RR's + owner name. If a bit is clear, it indicates that no RRset of that + type is present for the NSEC RR's owner name. + + Bits representing pseudo-types MUST be clear, since they do not + appear in zone data. If encountered, they MUST be ignored upon + reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + + + +Arends, et al. Expires January 13, 2005 [Page 15] + +Internet-Draft DNSSEC Resource Records July 2004 + + + interpreted as zero octets. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and the RR + types for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + + A zone MUST NOT include an NSEC RR for any domain name that only + holds glue records. + +4.1.3 Inclusion of Wildcard Names in NSEC RDATA + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for purposes of generating NSEC RRs. Wildcard owner names + appear in the Next Domain Name field without any wildcard expansion. + [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards + on authenticated denial of existence. + +4.2 The NSEC RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The Type Bit Maps field is represented as a sequence of RR type + mnemonics. When the mnemonic is not known, the TYPE representation + as described in [RFC3597] (section 5) MUST be used. + +4.3 NSEC RR Example + + The following NSEC RR identifies the RRsets associated with + alfa.example.com. and identifies the next authoritative name after + alfa.example.com. + + alfa.example.com. 86400 IN NSEC host.example.com. ( + A MX RRSIG NSEC TYPE1234 ) + + The first four text fields specify the name, TTL, Class, and RR type + (NSEC). The entry host.example.com. is the next authoritative name + after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, + and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and + TYPE1234 RRsets associated with the name alfa.example.com. + + The RDATA section of the NSEC RR above would be encoded as: + + + + + +Arends, et al. Expires January 13, 2005 [Page 16] + +Internet-Draft DNSSEC Resource Records July 2004 + + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x20 + + Assuming that the validator can authenticate this NSEC record, it + could be used to prove that beta.example.com does not exist, or could + be used to prove there is no AAAA record associated with + alfa.example.com. Authenticated denial of existence is discussed in + [I-D.ietf-dnsext-dnssec-protocol]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 17] + +Internet-Draft DNSSEC Resource Records July 2004 + + +5. The DS Resource Record + + The DS Resource Record refers to a DNSKEY RR and is used in the DNS + DNSKEY authentication process. A DS RR refers to a DNSKEY RR by + storing the key tag, algorithm number, and a digest of the DNSKEY RR. + Note that while the digest should be sufficient to identify the + public key, storing the key tag and key algorithm helps make the + identification process more efficient. By authenticating the DS + record, a resolver can authenticate the DNSKEY RR to which the DS + record points. The key authentication process is described in + [I-D.ietf-dnsext-dnssec-protocol]. + + The DS RR and its corresponding DNSKEY RR have the same owner name, + but they are stored in different locations. The DS RR appears only + on the upper (parental) side of a delegation, and is authoritative + data in the parent zone. For example, the DS RR for "example.com" is + stored in the "com" zone (the parent zone) rather than in the + "example.com" zone (the child zone). The corresponding DNSKEY RR is + stored in the "example.com" zone (the child zone). This simplifies + DNS zone management and zone signing, but introduces special response + processing requirements for the DS RR; these are described in + [I-D.ietf-dnsext-dnssec-protocol]. + + The type number for the DS record is 43. + + The DS resource record is class independent. + + The DS RR has no special TTL requirements. + +5.1 DS RDATA Wire Format + + The RDATA for a DS RR consists of a 2 octet Key Tag field, a one + octet Algorithm field, a one octet Digest Type field, and a Digest + field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | Digest Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 18] + +Internet-Draft DNSSEC Resource Records July 2004 + + +5.1.1 The Key Tag Field + + The Key Tag field lists the key tag of the DNSKEY RR referred to by + the DS record, in network byte order. + + The Key Tag used by the DS RR is identical to the Key Tag used by + RRSIG RRs. Appendix B describes how to compute a Key Tag. + +5.1.2 The Algorithm Field + + The Algorithm field lists the algorithm number of the DNSKEY RR + referred to by the DS record. + + The algorithm number used by the DS RR is identical to the algorithm + number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the + algorithm number types. + +5.1.3 The Digest Type Field + + The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY + RR. The Digest Type field identifies the algorithm used to construct + the digest. Appendix A.2 lists the possible digest algorithm types. + +5.1.4 The Digest Field + + The DS record refers to a DNSKEY RR by including a digest of that + DNSKEY RR. + + The digest is calculated by concatenating the canonical form of the + fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, + and then applying the digest algorithm. + + digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); + + "|" denotes concatenation + + DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. + + + The size of the digest may vary depending on the digest algorithm and + DNSKEY RR size. As of the time of writing, the only defined digest + algorithm is SHA-1, which produces a 20 octet digest. + +5.2 Processing of DS RRs When Validating Responses + + The DS RR links the authentication chain across zone boundaries, so + the DS RR requires extra care in processing. The DNSKEY RR referred + to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST + + + +Arends, et al. Expires January 13, 2005 [Page 19] + +Internet-Draft DNSSEC Resource Records July 2004 + + + have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC + zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in + the validation process. + +5.3 The DS RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic specified in Appendix A.1. + + The Digest Type field MUST be represented as an unsigned decimal + integer. + + The Digest MUST be represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is allowed within the hexadecimal + text. + +5.4 DS RR Example + + The following example shows a DNSKEY RR and its corresponding DS RR. + + dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A + 98631FAD1A292118 ) + + + The first four text fields specify the name, TTL, Class, and RR type + (DS). Value 60485 is the key tag for the corresponding + "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm + used by this "dskey.example.com." DNSKEY RR. The value 1 is the + algorithm used to construct the digest, and the rest of the RDATA + text is the digest in hexadecimal. + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 20] + +Internet-Draft DNSSEC Resource Records July 2004 + + +6. Canonical Form and Order of Resource Records + + This section defines a canonical form for resource records, a + canonical ordering of DNS names, and a canonical ordering of resource + records within an RRset. A canonical name order is required to + construct the NSEC name chain. A canonical RR form and ordering + within an RRset are required to construct and verify RRSIG RRs. + +6.1 Canonical DNS Name Order + + For purposes of DNS security, owner names are ordered by treating + individual labels as unsigned left-justified octet strings. The + absence of a octet sorts before a zero value octet, and upper case + US-ASCII letters are treated as if they were lower case US-ASCII + letters. + + To compute the canonical ordering of a set of DNS names, start by + sorting the names according to their most significant (rightmost) + labels. For names in which the most significant label is identical, + continue sorting according to their next most significant label, and + so forth. + + For example, the following names are sorted in canonical DNS name + order. The most significant label is "example". At this level, + "example" sorts first, followed by names ending in "a.example", then + names ending "z.example". The names within each level are sorted in + the same way. + + example + a.example + yljkjljk.a.example + Z.a.example + zABC.a.EXAMPLE + z.example + \001.z.example + *.z.example + \200.z.example + + +6.2 Canonical RR Form + + For purposes of DNS security, the canonical form of an RR is the wire + format of the RR where: + 1. Every domain name in the RR is fully expanded (no DNS name + compression) and fully qualified; + 2. All uppercase US-ASCII letters in the owner name of the RR are + replaced by the corresponding lowercase US-ASCII letters; + + + + +Arends, et al. Expires January 13, 2005 [Page 21] + +Internet-Draft DNSSEC Resource Records July 2004 + + + 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, + SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in + the DNS names contained within the RDATA are replaced by the + corresponding lowercase US-ASCII letters; + 4. If the owner name of the RR is a wildcard name, the owner name is + in its original unexpanded form, including the "*" label (no + wildcard substitution); and + 5. The RR's TTL is set to its original value as it appears in the + originating authoritative zone or the Original TTL field of the + covering RRSIG RR. + +6.3 Canonical RR Ordering Within An RRset + + For purposes of DNS security, RRs with the same owner name, class, + and type are sorted by treating the RDATA portion of the canonical + form of each RR as a left-justified unsigned octet sequence where the + absence of an octet sorts before a zero octet. + + [RFC2181] specifies that an RRset is not allowed to contain duplicate + records (multiple RRs with the same owner name, class, type, and + RDATA). Therefore, if an implementation detects duplicate RRs when + putting the RRset in canonical form, the implementation MUST treat + this as a protocol error. If the implementation chooses to handle + this protocol error in the spirit of the robustness principle (being + liberal in what it accepts), the implementation MUST remove all but + one of the duplicate RR(s) for purposes of calculating the canonical + form of the RRset. + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 22] + +Internet-Draft DNSSEC Resource Records July 2004 + + +7. IANA Considerations + + This document introduces no new IANA considerations, because all of + the protocol parameters used in this document have already been + assigned by previous specifications. However, since the evolution of + DNSSEC has been long and somewhat convoluted, this section attempts + to describe the current state of the IANA registries and other + protocol parameters which are (or once were) related to DNSSEC. + + Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA + considerations. + + DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to + the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS + Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, + and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. + [RFC3755] also marked type 30 (NXT) as Obsolete, and restricted + use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction + security protocol described in [RFC2931] and the transaction KEY + Resource Record described in [RFC2930]. + + DNS Security Algorithm Numbers: [RFC2535] created an IANA registry + for DNSSEC Resource Record Algorithm field numbers, and assigned + values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] + altered this registry to include flags for each entry regarding + its use with the DNS security extensions. Each algorithm entry + could refer to an algorithm that can be used for zone signing, + transaction security (see [RFC2931]) or both. Values 6-251 are + available for assignment by IETF standards action. See Appendix A + for a full listing of the DNS Security Algorithm Numbers entries + at the time of writing and their status of use in DNSSEC. + + [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and + assigned value 0 to reserved and value 1 to SHA-1. + + KEY Protocol Values: [RFC2535] created an IANA Registry for KEY + Protocol Values, but [RFC3445] re-assigned all values other than 3 + to reserved and closed this IANA registry. The registry remains + closed, and all KEY and DNSKEY records are required to have + Protocol Octet value of 3. + + Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA + registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, + this registry only contains an assignment for bit 7 (the ZONE bit) + and a reservation for bit 15 for the Secure Entry Point flag (SEP + bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by + IETF Standards Action. + + + + +Arends, et al. Expires January 13, 2005 [Page 23] + +Internet-Draft DNSSEC Resource Records July 2004 + + +8. Security Considerations + + This document describes the format of four DNS resource records used + by the DNS security extensions, and presents an algorithm for + calculating a key tag for a public key. Other than the items + described below, the resource records themselves introduce no + security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] + and [I-D.ietf-dnsext-dnssec-protocol] for additional security + considerations related to the use of these records. + + The DS record points to a DNSKEY RR using a cryptographic digest, the + key algorithm type and a key tag. The DS record is intended to + identify an existing DNSKEY RR, but it is theoretically possible for + an attacker to generate a DNSKEY that matches all the DS fields. The + probability of constructing such a matching DNSKEY depends on the + type of digest algorithm in use. The only currently defined digest + algorithm is SHA-1, and the working group believes that constructing + a public key which would match the algorithm, key tag, and SHA-1 + digest given in a DS record would be a sufficiently difficult problem + that such an attack is not a serious threat at this time. + + The key tag is used to help select DNSKEY resource records + efficiently, but it does not uniquely identify a single DNSKEY + resource record. It is possible for two distinct DNSKEY RRs to have + the same owner name, the same algorithm type, and the same key tag. + An implementation which uses only the key tag to select a DNSKEY RR + might select the wrong public key in some circumstances. + + The table of algorithms in Appendix A and the key tag calculation + algorithms in Appendix B include the RSA/MD5 algorithm for + completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as + explained in [RFC3110]. + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 24] + +Internet-Draft DNSSEC Resource Records July 2004 + + +9. Acknowledgments + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 25] + +Internet-Draft DNSSEC Resource Records July 2004 + + +10. References + +10.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-10 (work in progress), May + 2004. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in + progress), May 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + + + +Arends, et al. Expires January 13, 2005 [Page 26] + +Internet-Draft DNSSEC Resource Records July 2004 + + + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 3548, July 2003. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", RFC 3755, April 2004. + + [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", RFC 3757, April 2004. + +10.2 Informative References + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "DNSSEC NSEC RDATA Format", + draft-ietf-dnsext-nsec-rdata-06 (work in progress), May + 2004. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 27] + +Internet-Draft DNSSEC Resource Records July 2004 + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 28] + +Internet-Draft DNSSEC Resource Records July 2004 + + +Appendix A. DNSSEC Algorithm and Digest Types + + The DNS security extensions are designed to be independent of the + underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS + resource records all use a DNSSEC Algorithm Number to identify the + cryptographic algorithm in use by the resource record. The DS + resource record also specifies a Digest Algorithm Number to identify + the digest algorithm used to construct the DS record. The currently + defined Algorithm and Digest Types are listed below. Additional + Algorithm or Digest Types could be added as advances in cryptography + warrant. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1 DNSSEC Algorithm Types + + The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify + the security algorithm being used. These values are stored in the + "Algorithm number" field in the resource record RDATA. + + Some algorithms are usable only for zone signing (DNSSEC), some only + for transaction security mechanisms (SIG(0) and TSIG), and some for + both. Those usable for zone signing may appear in DNSKEY, RRSIG, and + DS RRs. Those usable for transaction security would be present in + SIG(0) and KEY RRs as described in [RFC2931] + + Zone + Value Algorithm [Mnemonic] Signing References Status + ----- -------------------- --------- ---------- --------- + 0 reserved + 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED + 2 Diffie-Hellman [DH] n RFC 2539 - + 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL + 4 Elliptic Curve [ECC] TBA - + 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY + 252 Indirect [INDIRECT] n - + 253 Private [PRIVATEDNS] y see below OPTIONAL + 254 Private [PRIVATEOID] y see below OPTIONAL + 255 reserved + + 6 - 251 Available for assignment by IETF Standards Action. + +A.1.1 Private Algorithm Types + + Algorithm number 253 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with a wire encoded + + + +Arends, et al. Expires January 13, 2005 [Page 29] + +Internet-Draft DNSSEC Resource Records July 2004 + + + domain name, which MUST NOT be compressed. The domain name indicates + the private algorithm to use and the remainder of the public key area + is determined by that algorithm. Entities should only use domain + names they control to designate their private algorithms. + + Algorithm number 254 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with an unsigned + length byte followed by a BER encoded Object Identifier (ISO OID) of + that length. The OID indicates the private algorithm in use and the + remainder of the area is whatever is required by that algorithm. + Entities should only use OIDs they control to designate their private + algorithms. + +A.2 DNSSEC Digest Types + + A "Digest Type" field in the DS resource record types identifies the + cryptographic digest algorithm used by the resource record. The + following table lists the currently defined digest algorithm types. + + VALUE Algorithm STATUS + 0 Reserved - + 1 SHA-1 MANDATORY + 2-255 Unassigned - + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 30] + +Internet-Draft DNSSEC Resource Records July 2004 + + +Appendix B. Key Tag Calculation + + The Key Tag field in the RRSIG and DS resource record types provides + a mechanism for selecting a public key efficiently. In most cases, a + combination of owner name, algorithm, and key tag can efficiently + identify a DNSKEY record. Both the RRSIG and DS resource records + have corresponding DNSKEY records. The Key Tag field in the RRSIG + and DS records can be used to help select the corresponding DNSKEY RR + efficiently when more than one candidate DNSKEY RR is available. + + However, it is essential to note that the key tag is not a unique + identifier. It is theoretically possible for two distinct DNSKEY RRs + to have the same owner name, the same algorithm, and the same key + tag. The key tag is used to limit the possible candidate keys, but + it does not uniquely identify a DNSKEY record. Implementations MUST + NOT assume that the key tag uniquely identifies a DNSKEY RR. + + The key tag is the same for all DNSKEY algorithm types except + algorithm 1 (please see Appendix B.1 for the definition of the key + tag for algorithm 1). The key tag algorithm is the sum of the wire + format of the DNSKEY RDATA broken into 2 octet groups. First the + RDATA (in wire format) is treated as a series of 2 octet groups, + these groups are then added together ignoring any carry bits. + + A reference implementation of the key tag algorithm is as an ANSI C + function is given below with the RDATA portion of the DNSKEY RR is + used as input. It is not necessary to use the following reference + code verbatim, but the numerical value of the Key Tag MUST be + identical to what the reference implementation would generate for the + same input. + + Please note that the algorithm for calculating the Key Tag is almost + but not completely identical to the familiar ones complement checksum + used in many other Internet protocols. Key Tags MUST be calculated + using the algorithm described here rather than the ones complement + checksum. + + The following ANSI C reference implementation calculates the value of + a Key Tag. This reference implementation applies to all algorithm + types except algorithm 1 (see Appendix B.1). The input is the wire + format of the RDATA portion of the DNSKEY RR. The code is written + for clarity, not efficiency. + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 31] + +Internet-Draft DNSSEC Resource Records July 2004 + + + /* + * Assumes that int is at least 16 bits. + * First octet of the key tag is the most significant 8 bits of the + * return value; + * Second octet of the key tag is the least significant 8 bits of the + * return value. + */ + + unsigned int + keytag ( + unsigned char key[], /* the RDATA part of the DNSKEY RR */ + unsigned int keysize /* the RDLENGTH */ + ) + { + unsigned long ac; /* assumed to be 32 bits or larger */ + int i; /* loop index */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i & 1) ? key[i] : key[i] << 8; + ac += (ac >> 16) & 0xFFFF; + return ac & 0xFFFF; + } + + +B.1 Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently than the + key tag for all other algorithms, for historical reasons. For a + DNSKEY RR with algorithm 1, the key tag is defined to be the most + significant 16 bits of the least significant 24 bits in the public + key modulus (in other words, the 4th to last and 3rd to last octets + of the public key modulus). + + Please note that Algorithm 1 is NOT RECOMMENDED. + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 13, 2005 [Page 32] + +Internet-Draft DNSSEC Resource Records July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires January 13, 2005 [Page 33] + + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt new file mode 100644 index 0000000000..42c3c0b7c7 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt @@ -0,0 +1,1321 @@ + +DNS Operations WG +Internet-Draft J. Jeong (ed.) + ETRI + +Expires: January 2005 18 July 2004 + + + IPv6 Host Configuration of DNS Server Information Approaches + draft-ietf-dnsop-ipv6-dns-configuration-02.txt + + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which we become aware will be disclosed, in accordance + with RFC3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 17, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document describes three approaches for IPv6 recursive DNS + server address configuration. It details the operational + attributes of three solutions: RA option, DHCPv6 option, and Well- + known anycast addresses for recursive DNS servers. Additionally, + it suggests four deployment scenarios considering multi-solution + resolution. Therefore, this document will give the audience a + + + +Jeong, et al. Expires - January 2005 [Page 1] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + guideline of IPv6 DNS configuration to select approaches suitable + for their host DNS configuration. + +Table of Contents + + 1. Introduction...................................................3 + 2. Terminology....................................................3 + 3. IPv6 DNS Configuration Approaches..............................3 + 3.1 RA Option..................................................3 + 3.1.1 Advantages...........................................4 + 3.1.2 Disadvantages........................................5 + 3.1.3 Observations.........................................5 + 3.2 DHCPv6 Option..............................................6 + 3.2.1 Advantages...........................................7 + 3.2.2 Disadvantages........................................8 + 3.2.3 Observations.........................................9 + 3.3 Well-known Anycast Addresses...............................9 + 3.3.1 Advantages...........................................9 + 3.3.2 Disadvantages.......................................10 + 3.3.3 Observations........................................10 + 4. Interworking among IPv6 DNS Configuration Approaches..........11 + 5. Deployment Scenarios..........................................12 + 5.1 ISP Network...............................................12 + 5.1.1 RA Option Approach..................................12 + 5.1.2 DHCPv6 Option Approach..............................13 + 5.1.3 Well-known Addresses Approach.......................13 + 5.2 Enterprise Network........................................14 + 5.3 3GPP Network..............................................14 + 5.3.1 Currently Available Mechanisms and Recommendations..15 + 5.3.2 RA Extension........................................16 + 5.3.3 Stateless DHCPv6....................................16 + 5.3.4 Well-known Addresses................................17 + 5.3.5 Recommendations.....................................17 + 5.4 Unmanaged Network.........................................18 + 5.4.1 Case A: Gateway does not provide IPv6 at all........18 + 5.4.2 Case B: A dual-stack gateway connected to a dual-stack + ISP.........................................18 + 5.4.3 Case C: A dual-stack gateway connected to an IPv4-only + ISP.........................................19 + 5.4.4 Case D: A gateway connected to an IPv6-only ISP.....19 + 6. Security Considerations.......................................19 + 7. Acknowledgements..............................................19 + 8. Normative References..........................................20 + 9. Informative References........................................20 + 10. Authors' Addresses...........................................21 + Intellectual Property Statement..................................23 + Full Copyright Statement.........................................23 + Acknowledgement..................................................24 + + +Jeong, et al. Expires - January 2005 [Page 2] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + +1. Introduction + + Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address + Autoconfiguration provide ways to configure either fixed or mobile + nodes with one or more IPv6 addresses, default routes and some + other parameters [3][4]. To support access to additional services + in the Internet that are identified by a DNS name, such as a web + server, the configuration of at least one recursive DNS server is + also needed for DNS name resolution. + + This document describes three approaches of recursive DNS server + address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 + option [5]-[7], and (c) Well-known anycast addresses for recursive + DNS servers [9]. Also, it suggests applicable scenarios for four + kinds of networks: (a) ISP network, (b) Enterprise network, (c) + 3GPP network, and (d) Unmanaged network. + + This document is just an analysis of each possible approach, and + does not make any recommendation on particular one or on a + combination of particular ones. Some approaches may even not be + adopted at all as a result of further discussion. + + Therefore, the objective of this document is to help the audience + select approaches suitable for IPv6 host configuration of recursive + DNS server. + +2. Terminology + + This document uses the terminology described in [3]-[9]. In + addition, a new term is defined below: + + Recursive DNS Server (RDNSS) A Recursive DNS Server is a name + server that offers the recursive + service of DNS name resolution. + +3. IPv6 DNS Configuration Approaches + + In this section, the operational attributes of three solutions are + described in detail. + +3.1 RA Option + + RA approach is to define a new ND option called RDNSS option that + contains a recursive DNS server address. Existing ND transport + mechanisms (i.e., advertisements and solicitations) are used. This + works in the same way that nodes learn about routers and prefixes, + etc. An IPv6 host can configure the IPv6 addresses of one or more + + +Jeong, et al. Expires - January 2005 [Page 3] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + RDNSSes via RA message periodically sent by router or solicited by + a Router Solicitation (RS) [8]. This approach needs RDNSS + information to be configured in the routers doing the + advertisements. The configuration of RDNSS address can be + performed manually by operator or other ways, such as automatic + configuration through DHCPv6 client running on the router. When + advertising more than one RDNSS options, an RA message includes as + many RDNSS options as RDNSSes. Through ND protocol and RDNSS + option along with prefix information option, an IPv6 host can + perform its network configuration of its IPv6 address and RDNSS + simultaneously [3][4]. The RA option for RDNSS can be used on any + network that supports the use of ND. However, RA approach performs + poorly in some wireless environments where RA message is used for + IPv6 address autoconfiguration, such as WLAN networks. + + The RA approach is useful in some non-WLAN mobile environments + where the addresses of the RDNSSes are changing because the RA + option includes a lifetime field. This can be configured to a + value that will require the client to time out the entry and switch + over to another RDNSS address [8]. However, from the viewpoint of + implementation, lifetime would seem to make matters a bit more + complex. Instead of just writing DNS configuration file, such as + resolv.conf for the list of RDNSS addresses, we have to have a + daemon around (or a program that is called at the defined + intervals) that keeps monitoring the lifetime of RDNSSes all the + time. + + The preference value of RDNSS, included in RDNSS option, allows + IPv6 hosts to select primary RDNSS among several RDNSSes; this can + be used for load balancing of RDNSSes [8]. + +3.1.1 Advantages + + The RA option for RDNSS has a number of advantages. These include: + + 1) The RA option is an extension of existing ND/Autoconfig + mechanisms [3][4], and does not require a change in the base ND + protocol. + + 2) This approach, like ND, works well on a variety of link types + including point-to-point links, point-to-multipoint, and multi- + point (i.e., Ethernet LANs), etc. RFC2461 [3] states, however, + that there may be some link type on which ND is not possible; on + such a link, some other mechanism will be needed for DNS + configuration. + + 3) All of the information a host needs to run basic Internet + applications such as email, the web, ftp, etc., can be performed + + +Jeong, et al. Expires - January 2005 [Page 4] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + with the addition of this option to ND and address auto- + configuration. The use of a single mechanism is more reliable and + easier to provide than when the RDNSS information is learned via + another protocol mechanism. Debugging problems when multiple + protocol mechanisms are being used is harder and much more complex. + + 4) This mechanism works over a broad range of scenarios and + leverages IPv6 ND. This works well on links that support broadcast + reliably (e.g., Ethernet LANs) but not necessarily on other links + (e.g., Wireless LANs). Also, this works well on links that are + high performance (e.g., Ethernet LANs) and low performance (e.g., + Cellular networks). In the latter case, combining the RDNSS + information with the other information in the RA, the host can + learn all of the information needed to use most Internet + applications such as the web in a single packet. This not only + saves bandwidth where this is an issue, but also minimizes the + delay to learn the RDNSS information. + + 5) The RA approach could be used as a model for other similar types + of configuration information. New RA options for other server + addresses that are common to all clients on a subnet would be easy + to define. This includes things like NTP servers, SIP servers, etc. + +3.1.2 Disadvantages + + 1) ND is mostly implemented in kernel part of operating system. + Therefore, if ND supports the configuration of some additional + services, such as DNS, NTP and SIP servers, ND should be extended + in kernel part. DHCPv6, however, has more flexibility for + extension of service discovery because it is an application layer + protocol. + + 2) The current ND framework should be modified due to the + synchronization between another ND cache for RDNSSes in kernel + space and DNS configuration file in user space. Because it is + unacceptable to write and rewrite the DNS configuration file (e.g., + resolv.conf) from the kernel, another approach is needed. One + simple approach to solve this is to have a daemon listening to what + the kernel conveys, and to have the daemon do these steps, but such + a daemon is not necessary with the current ND framework. + + 3) It is necessary to configure RDNSS addresses at least at one + router on every link where this information needs to be configured + by RA option. + +3.1.3 Observations + + + + +Jeong, et al. Expires - January 2005 [Page 5] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + The proposed RDNSS RA option along with IPv6 ND and Auto- + configuration allows a host to obtain all of the information it + needs to access basic Internet services like the web, email, ftp, + etc. This is preferable in environments where hosts use RAs to + autoconfigure their addresses and all hosts on the subnet share the + same router and server addresses. If the configuration information + can be obtained from a single mechanism, it is preferable because + it does not add additional delay, and it uses a minimum of + bandwidth. Environments like this include homes, public cellular + networks, and enterprise environments where no per host + configuration is needed, but exclude public WLAN hot spots. + + DHCPv6 is preferable where it is being used for address + configuration and if there is a need for host specific + configuration [5]-[7]. Environments like this are most likely + enterprise environments where the local administration chooses to + have per host configuration control. + + Note: the observation section is based on what the proponents of + each approach think makes a good overall solution. + +3.2 DHCPv6 Option + + DHCPv6 [5] includes the "DNS Recursive Name Server" option, through + which a host can obtain a list of IP addresses of recursive DNS + servers [7]. The DNS Recursive Name Server option carries a list + of IPv6 addresses of RDNSSes to which the host may send DNS queries. + The DNS servers are listed in the order of preference for use by + the DNS resolver on the host. + + The DNS Recursive Name Server option can be carried in any DHCPv6 + Reply message, in response to either a Request or an Information- + request message. Thus, the DNS Recursive Name Server option can be + used either when DHCPv6 is used for address assignment, or when + DHCPv6 is used only for other configuration information as + stateless DHCPv6 [6]. + + Stateless DHCPv6 can be deployed either using DHCPv6 servers + running on general-purpose computers, or on router hardware. + Several router vendors currently implement stateless DHCPv6 servers. + Deploying stateless DHCPv6 in routers has the advantage that no + special hardware is required, and should work well for networks + where DHCPv6 is needed for very straightforward configuration of + network devices. + + However, routers can also act as DHCPv6 relay agents. In this case, + the DHCPv6 server need not be on the router - it can be on a + general purpose computer. This has the potential to give the + + +Jeong, et al. Expires - January 2005 [Page 6] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + operator of the DHCPv6 server more flexibility in how the DHCPv6 + server responds to individual clients - clients can easily be given + different configuration information based on their identity, or for + any other reason. Nothing precludes adding this flexibility to a + router, but generally in current practice, DHCP servers running on + general-purpose hosts tend to have more configuration options than + those that are embedded in routers. + + DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 + clients that use stateful configuration assignment. To do this, + the DHCPv6 server sends a Reconfigure message to the client. The + client validates the Reconfigure message, and then contacts the + DHCPv6 server to obtain updated configuration information. Using + this mechanism, it is currently possible to propagate new + configuration information to DHCPv6 clients as this information + changes. + + The DHC Working Group is currently studying an additional mechanism + through which configuration information, including the list of + RDNSSes, can be updated. The Lifetime Option for DHCPv6 [10], + assigns a lifetime to configuration information obtained through + DHCPv6. At the expiration of the lifetime, the host contacts the + DHCPv6 server to obtain updated configuration information, + including the list of RDNSSes. This lifetime gives the network + administrator another mechanism to configure hosts with new RDNSSes + by controlling the time at which the host refreshes the list. + + The DHC Working Group has also discussed the possibility of + defining an extension to DHCPv6 that would allow the use of + multicast to provide configuration information to multiple hosts + with a single DHCPv6 message. Because of the lack of deployment + experience, the WG has deferred consideration of multicast DHCPv6 + configuration at this time. Experience with DHCPv4 has not + identified a requirement for multicast message delivery, even in + large service provider networks with tens of thousands of hosts + that may initiate a DHCPv4 message exchange simultaneously. + +3.2.1 Advantages + + The DHCPv6 option for RDNSS has a number of advantages. These + include: + + 1) DHCPv6 currently provides a general mechanism for conveying + network configuration information to clients. So configuring + DHCPv6 servers allows the network administrator to configure + RDNSSes along with the addresses of other network services, as well + as location-specific information like time zones. + + + +Jeong, et al. Expires - January 2005 [Page 7] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + 2) As a consequence, when the network administrator goes to + configure DHCPv6, all the configuration information can be managed + through a single service, typically with a single user interface + and a single configuration database. + + 3) DHCPv6 allows for the configuration of a host with information + specific to that host, so that hosts on the same link can be + configured with different RDNSSes as well as other configuration + information. This capability is important in some network + deployments such as service provider networks or WiFi hot spots. + + 4) A mechanism exists for extending DHCPv6 to support the + transmission of additional configuration that has not yet been + anticipated. + + 5) Hosts that require other configuration information such as the + addresses of SIP servers and NTP servers are likely to need DHCPv6 + for other configuration information. + + 6) The specification for configuration of RDNSSes through DHCPv6 is + available as an RFC. No new protocol extensions such as new + options are necessary. + + 7) Interoperability among independent implementations has been + demonstrated. + +3.2.2 Disadvantages + + The DHCPv6 option for RDNSS has a few disadvantages. These + include: + + 1) Update currently requires message from server (however, see + [10]). + + 2) Because DNS information is not contained in RA message, the host + must receive two messages from the router, and must transmit at + least one message to the router. On networks where bandwidth is at + a premium, this is a disadvantage, although on most networks it is + not a practical concern. + + 3) Increased latency for initial configuration - in addition to + waiting for an RA message, the client must now exchange packets + with a DHCPv6 server; even if it is locally installed on a router, + this will slightly extend the time required to configure the client. + For clients that are moving rapidly from one network to another, + this will be a disadvantage. + + + + +Jeong, et al. Expires - January 2005 [Page 8] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + +3.2.3 Observations + + In the general case, on general-purpose networks, stateless DHCPv6 + provides significant advantages and no significant disadvantages. + Even in the case where bandwidth is at a premium and low latency is + desired, if hosts require other configuration information in + addition to a list of RDNSSes or if hosts must be configured + selectively, those hosts will use DHCPv6 and the use of the DHCPv6 + DNS recursive name server option will be advantageous. + + However, we are aware of some applications where it would be + preferable to put the RDNSS information into an RA packet; for + example, on a cell phone network, where bandwidth is at a premium + and extremely low latency is desired. The final DNS configuration + draft should be written so as to allow these special applications + to be handled using DNS information in the RA packet. + +3.3 Well-known Anycast Addresses + + First of all, the well-known anycast addresses approach is much + different from that discussed in IPv6 Working Group in the past. + + The approach with well-known anycast addresses is to set well-known + anycast addresses in clients' resolver configuration files from the + beginning, say, as factory default. Thus, there is no transport + mechanism and no packet format [9]. + + An anycast address is an address shared by multiple servers (in + this case, the servers are RDNSSes). Request from a client to the + anycast address is routed to a server selected by the routing + system. However, it is a bad idea to mandate "site" boundary on + anycast addresses, because most users just do not have their own + servers and want to access their ISPs' across their site boundaries. + Larger sites may also depend on their ISPs or may have their own + RDNSSes within "site" boundaries. + + It should be noted that "anycast" in this memo is simpler than that + of RFC1546 [11] and RFC3513 [12] where it is assumed to be + prohibited to have multiple servers on a single link sharing an + anycast address. That is, on a link, anycast address is assumed to + be unique. DNS clients today already have redundancy by having + multiple well-known anycast addresses configured as RDNSS addresses. + There is no point to have multiple RDNSSes sharing an anycast + address on a single link. + +3.3.1 Advantages + + + + +Jeong, et al. Expires - January 2005 [Page 9] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + The basic advantage of the well-known addresses approach is that it + uses no transport mechanism. Thus, + 1) There is no delay to get response and no further delay by packet + losses. + + 2) The approach can be combined with any other configuration + mechanisms including but not limited to factory default + configuration, RA-based approach and DHCP based approach. + + 3) The approach works over any environment where DNS works. + + Another advantage is that the approach needs to configure DNS + servers as a router, but nothing else. Considering that DNS + servers do need configuration, the amount of overall configuration + effort is proportional to the number of the DNS servers and scales + linearly. It should be noted that, in the simplest case where a + subscriber to an ISP does not have any DNS server, the subscriber + naturally access DNS servers of the ISP even though the subscriber + and the ISP do nothing and there is no protocol to exchange DNS + server information between the subscriber and the ISP. + +3.3.2 Disadvantages + + Well-known anycast addresses approach requires that DNS servers (or + routers near it as a proxy) act as routers to advertise their + anycast addresses to the routing system, which requires some + configuration (see the last paragraph of the previous section on + the scalability of the effort). + +3.3.3 Observations + + If other approaches are used in addition, the well-known anycast + addresses should also be set in RA or DHCP configuration files to + reduce configuration effort of users. + + Redundancy by multiple RDNSSes is better provided by multiple + servers having different anycast addresses than multiple servers + sharing same anycast address because the former approach allows + stale servers to still generate routes to their anycast addresses. + Thus, in a routing domain (or domains sharing DNS servers), there + will be only one server having an anycast address unless the domain + is so large that load distribution is necessary. + + Small ISPs will operate one RDNSS at each anycast address which is + shared by all the subscribers. Large ISPs may operate multiple + RDNSSes at each anycast address to distribute and reduce load, + where boundary between RDNSSes may be fixed (redundancy is still + provided by multiple addresses) or change dynamically. DNS packets + + +Jeong, et al. Expires - January 2005 [Page 10] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + with the well-known anycast addresses are not expected (though not + prohibited) to cross ISP boundaries, as ISPs are expected to be + able to take care of themselves. + + Because "anycast" in this memo is simpler than that of RFC1546 [11] + and RFC3513 [12] where it is assumed to be administratively + prohibited to have multiple servers on a single link sharing an + anycast address, anycast in this memo should be implemented as + UNICAST of RFC2461 [3] and RFC3513 [12]. As a result, ND-related + instability disappears. Thus, anycast in well-known anycast + addresses approach can and should use the anycast address as a + source unicast (according to RFC3513 [12]) address of packets of + UDP and TCP responses. With TCP, if route flips and packets to an + anycast address are routed to a new server, it is expected that the + flip is detected by ICMP or sequence number inconsistency and the + TCP connection is reset and retried. + +4. Interworking among IPv6 DNS Configuration Approaches + + Three approaches can work together for IPv6 host configuration of + RDNSS. This section shows a consideration on how these approaches + can interwork each other. + + For ordering between RA and DHCP approaches, O (Other stateful + configuration) flag in RA message can be used [8]. If no RDNSS + option is included, an IPv6 Host may perform DNS configuration + through DHCPv6 [5]-[7] regardless of whether the O flag is set or + not. + + The well-known anycast addresses approach fully interworks with the + other approaches. That is, the other approaches can remove + configuration effort on servers by using the well-known addresses + as the default configuration. Moreover, clients preconfigured with + well-known anycast addresses can be further configured to use other + approaches to override the well-known addresses, if configuration + information from other approaches are available. That is, all the + clients should have the well-known anycast addresses preconfigured, + in the case where there are no other mechanisms available. In + order to fly anycast approach with the other solutions, there are + three options. + + The first option is that well-known addresses are used as last + resort, when an IPv6 host can not get RDNSS information through RA + and DHCP. The well-known anycast addresses have to be pre- + configured in IPv6 hosts' resolver configuration files. + + + + + +Jeong, et al. Expires - January 2005 [Page 11] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + The second is that an IPv6 host can configure well-known addresses + as the most preferable in its configuration file even though either + RA option or DHCP option is available. + + The last is that the well-known anycast addresses can be set in RA + or DHCP configuration to reduce configuration effort of users. + According to either RA or DHCP mechanism, the well-known addresses + can be obtained by IPv6 host. Because this approach is the most + convenient for users, the last option is recommended. + + Note: this section does not necessarily mean this document suggests + adopting all these three approaches and making them interwork in + the way described here. In fact, some approaches may even not be + adopted at all as a result of further discussion. + +5. Deployment Scenarios + + Regarding DNS configuration on the IPv6 host, several mechanisms + have being considered at the DNSOP Working Group such as RA option, + DHCPv6 option and well-known preconfigured anycast addresses as of + today, and this document is a final result from the long thread. + In this section, we suggest four applicable scenarios of three + approaches for IPv6 DNS configuration. + + Note: in the applicable scenarios, authors do not implicitly push + any specific approaches into the restricted environments. No + enforcement is in each scenario and all mentioned scenarios are + probable. The main objective of this work is to provide a useful + guideline of IPv6 DNS configuration. + +5.1 ISP Network + + A characteristic of ISP network is that multiple Customer Premises + Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) + routers and each PE connects multiple CPE devices to the backbone + network infrastructure [13]. The CPEs may be hosts or routers. + + In the case where the CPE is a router, there is a customer network + that is connected to the ISP backbone through the CPE. Typically, + each customer network gets a different IPv6 prefix from an IPv6 PE + router, but the same RDNSS configuration will be distributed. + + This section discusses how the different approaches to distributing + DNS information are compared in an ISP network. + +5.1.1 RA Option Approach + + + + +Jeong, et al. Expires - January 2005 [Page 12] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + When the CPE is a host, the RA option for RDNSS can be used to + allow the CPE to get RDNSS information as well as /64 prefix + information for stateless address autoconfiguration at the same + time when the host is attached to a new subnet [8]. Because an + IPv6 host must receive at least one RA message for stateless + address autoconfiguration and router configuration, the host could + receive RDNSS configuration information in that RA without the + overhead of an additional message exchange. + + When the CPE is a router, the CPE may accept the RDNSS information + from the RA on the interface connected to the ISP, and copy that + information into the RAs advertised in the customer network. + + This approach is more valuable in the mobile host scenario, in + which the host must receive at least an RA message for detecting a + new network, than in other scenarios generally although + administrator should configure RDNSS information on the routers. + Secure ND [14] can provide extended security when using RA message. + +5.1.2 DHCPv6 Option Approach + + DHCPv6 can be used for RDNSS configuration through the use of the + DNS option, and can provide other configuration information in the + same message with RDNSS configuration [5]-[7]. DHCPv6 DNS option + is already in place for DHCPv6 as RFC 3646 [7] and moreover DHCPv6- + lite or stateless DHCP [6] is nowhere as complex as a full DHCPv6 + implementation. DHCP is a client-server model protocol, so ISP can + handle user identification on its network intentionally, and also + authenticated DHCP [15] can be used for secure message exchange. + + The expected model for deployment of IPv6 service by ISPs is to + assign a prefix to each customer, which will be used by the + customer gateway to assign a /64 prefix to each network in the + customer's network. Prefix delegation with DHCP (DHCPv6 PD) has + already been adopted by ISPs for automating the assignment of the + customer prefix to the customer gateway [17]. DNS configuration + can be carried in the same DHCPv6 message exchange used for DHCPv6 + to efficiently provide that information, along with any other + configuration information needed by the customer gateway or + customer network. This service model can be useful to Home or SOHO + subscribers. The Home or SOHO gateway, which is a customer gateway + for ISP, can then pass that RDNSS configuration information to the + hosts in the customer network through DHCP. + +5.1.3 Well-known Addresses Approach + + Well-known anycast addresses approach is also a feasible and simple + mechanism for ISP [9]. The use of well-known anycast addresses + + +Jeong, et al. Expires - January 2005 [Page 13] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + avoids some of the security risks in rogue messages sent through an + external protocol like RA or DHCPv6. The configuration of hosts + for the use of well-known anycast addresses requires no protocol or + manual configuration, but the configuration of routing for the + anycast addresses requires intervention on the part of the network + administrator. Also, the number of special addresses would be + equal to the number of RDNSSes that could be made available to + subscribers. + +5.2 Enterprise Network + + Enterprise network is defined as a network that has multiple + internal links, one or more router connections, to one or more + Providers and is actively managed by a network operations entity + [16]. An enterprise network can get network prefixes from ISP by + either manual configuration or prefix delegation [17]. In most + cases, because an enterprise network manages its own DNS domains, + it operates its own DNS servers for the domains. These DNS servers + within enterprise network process recursive DNS name resolution + requests of IPv6 hosts as RDNSS. RDNSS configuration in enterprise + network can be performed like in Section 4, in which three + approaches can be used together. + + IPv6 host can decide which approach is or may be used in its subnet + with O flag in RA message [8]. As the first option in Section 4, + well-known anycast addresses can be used as a last resort when + RDNSS information can not be obtained through either RA option or + DHCP option. This case needs IPv6 hosts to preconfigure the well- + known anycast addresses in their DNS configuration files. + + When the enterprise prefers well-known anycast approach to the + others, IPv6 hosts should preconfigure the well-known anycast + addresses like in the first option. + + The last option, a more convenient and transparent way, does not + need IPv6 hosts to preconfigure the well-known anycast addresses + because the addresses are delivered to IPv6 hosts through either RA + option or DHCPv6 option as if they were unicast addresses. This + way is most recommended for the sake of user's convenience. + +5.3 3GPP Network + + IPv6 DNS configuration is a missing part of IPv6 autoconfiguration + and an important part of the basic IPv6 functionality in the 3GPP + User Equipment (UE). Higher level description of the 3GPP + architecture can be found in [18], and transition to IPv6 in 3GPP + networks is analyzed in [19] and [20]. + + + +Jeong, et al. Expires - January 2005 [Page 14] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + In 3GPP architecture, there is a dedicated link between the UE and + the GGSN called the Packet Data Protocol (PDP) Context. This link + is created through the PDP Context activation procedure [21]. + There is a separate PDP context type for IPv4 and IPv6 traffic. If + a 3GPP UE user is communicating using IPv6 (having an active IPv6 + PDP context), it can not be assumed that (s)he has simultaneously + active IPv4 PDP context, and DNS queries could be done using IPv4. + A 3GPP UE can thus be an IPv6 node, and it needs to somehow + discover the address of the RDNSS. Before IP-based services (e.g., + web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS + addresses need to be discovered in the 3GPP UE. + + Section 5.3.1 briefly summarizes currently available mechanisms in + 3GPP networks and recommendations. 5.3.2 analyzes the Router + Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 + mechanism, and 5.3.4 analyzes the Well-known addresses approach. + Section 5.3.5 finally summarizes the recommendations. + +5.3.1 Currently Available Mechanisms and Recommendations + + 3GPP has defined a mechanism, in which RDNSS addresses can be + received in the PDP context activation (a control plane mechanism). + That is called the Protocol Configuration Options Information + Element (PCO-IE) mechanism [22]. The RDNSS addresses can also be + received over the air (using text messages), or typed in manually + in the UE. Note that the two last mechanisms are not very well + scalable. The UE user most probably does not want to type IPv6 + RDNSS addresses manually in his/her UE. The use of well-known + addresses is briefly discussed in section 5.3.4. + + It is seen that the mechanisms above most probably are not + sufficient for the 3GPP environment. IPv6 is intended to operate + in a zero-configuration manner, no matter what the underlying + network infrastructure is. Typically, the RDNSS address is needed + to make an IPv6 node operational - and the DNS configuration should + be as simple as the address autoconfiguration mechanism. It must + also be noted that there will be additional IP interfaces in some + near future 3GPP UEs, e.g., Wireless LAN (WLAN), and 3GPP-specific + DNS configuration mechanisms (such as PCO-IE [22]) do not work for + those IP interfaces. In other words, a good IPv6 DNS configuration + mechanism should also work in a multi-access network environment. + + From 3GPP point of view, the best IPv6 DNS configuration solution + is feasible for a very large number of IPv6-capable UEs (can be + even hundreds of millions in one operator's network), is automatic + and thus requires no user action. It is suggested to standardize a + lightweight, stateless mechanism that works in all network + environments. The solution could then be used for 3GPP, 3GPP2, + + +Jeong, et al. Expires - January 2005 [Page 15] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + WLAN and other access network technologies. A light, stateless + IPv6 DNS configuration mechanism is thus not only needed in 3GPP + networks, but also 3GPP networks and UEs would certainly benefit + from the new mechanism. + +5.3.2 RA Extension + + Router Advertisement extension [8] is a lightweight IPv6 DNS + configuration mechanism that requires minor changes in 3GPP UE IPv6 + stack and Gateway GPRS Support Node (GGSN, the default router in + the 3GPP architecture) IPv6 stack. This solution can be specified + in the IETF (no action needed in the 3GPP) and taken in use in 3GPP + UEs and GGSNs. + + In this solution, an IPv6-capable UE configures DNS information + via RA message sent by its default router (GGSN), i.e., RDNSS + option for recursive DNS server is included in the RA message. + This solution is easily scalable for a very large number of UEs. + The operator can configure the RDNSS addresses in the GGSN as a + part of normal GGSN configuration. The IPv6 RDNSS address is + received in the Router Advertisement, and an extra Round Trip Time + (RTT) for asking RDNSS addresses can be avoided. + + If thinking about cons, this mechanism still requires + standardization effort in the IETF, and the end nodes and routers + need to support this mechanism. The equipment software update + should, however, be pretty straightforward, and new IPv6 equipment + could support RA extension already from the beginning. + +5.3.3 Stateless DHCPv6 + + DHCPv6-based solution needs the implementation of Stateless DHCP + [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in + the operator's network. A possible configuration is such that the + GGSN works as a DHCP relay. + + Pros for Stateless DHCPv6-based solution are + 1) Stateless DHCPv6 is a standardized mechanism. + + 2) DHCPv6 can be used for receiving other configuration information + than RDNSS addresses, e.g., SIP server addresses. + + 3) DHCPv6 works in different network environments. + + 4) When DHCPv6 service is deployed through a single, centralized + server, the RDNSS configuration information can be updated by the + network administrator at a single source. + + + +Jeong, et al. Expires - January 2005 [Page 16] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + Some issues with DHCPv6 in 3GPP networks are listed below: + 1) DHCPv6 requires an additional server in the network unless the + (Stateless) DHCPv6 functionality is integrated into an existing + router already, and it is one box more to be maintained. + + 2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing + (3GPP Stateless Address Autoconfiguration is typically used), and + not automatically implemented in 3GPP IPv6 UEs. + + 3) Scalability and reliability of DHCPv6 in very large 3GPP + networks (with tens or hundreds of millions of UEs) may be an issue, + at least the redundancy needs to be taken care of. However, if the + DHCPv6 service is integrated into the network elements, such as + router operating system, scalability and reliability is comparable + with other DNS configuration approaches. + + 4) It is sub-optimal to utilize the radio resources in 3GPP + networks for DHCPv6 messages if there is a simpler alternative + available. + + a) Use of Stateless DHCPv6 adds one round trip delay to the case + in which the UE can start transmitting data right after the + Router Advertisement. + + 5) If the DNS information (suddenly) changes, Stateless DHCPv6 can + not automatically update the UE, see [23]. + +5.3.4 Well-known Addresses + + Using well-known addresses is also a feasible and a light mechanism + for 3GPP UEs. Those well-known addresses can be preconfigured in + the UE software and the operator makes the corresponding + configuration on the network side. So this is a very easy + mechanism for the UE, but requires some configuration work in the + network. When using well-known addresses, UE forwards queries to + any of the preconfigured addresses. In the current proposal [9], + IPv6 anycast addresses are suggested. + + Note: IPv6 DNS configuration proposal based on the use of well- + known site-local addresses developed at the IPv6 Working Group was + seen as a feasible mechanism for 3GPP UEs, but opposition by some + people in the IETF and finally deprecating IPv6 site-local + addresses made it impossible to standardize it. Note that this + mechanism is implemented in some existing operating systems today + (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration. + +5.3.5 Recommendations + + + +Jeong, et al. Expires - January 2005 [Page 17] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + It is suggested that a lightweight, stateless DNS configuration + mechanism is specified as soon as possible. From 3GPP UE's and + networks' point of view, Router Advertisement based mechanism looks + most promising. The sooner a light, stateless mechanism is + specified, the sooner we can get rid of using well-known site-local + addresses for IPv6 DNS configuration. + +5.4 Unmanaged Network + + There are 4 deployment scenarios of interest in unmanaged networks + [24]: + + 1) A gateway which does not provide IPv6 at all; + + 2) A dual-stack gateway connected to a dual-stack ISP; + + 3) A dual-stack gateway connected to an IPv4-only ISP; and + + 4) A gateway connected to an IPv6-only ISP. + +5.4.1 Case A: Gateway does not provide IPv6 at all + + In this case, the gateway does not provide IPv6; the ISP may or may + not provide IPv6. Automatic or Configured tunnels are the + recommended transition mechanisms for this scenario. + + The case where dual-stack hosts behind an NAT, that need access to + an IPv6 RDNSS, can not be entirely ruled out. The DNS + configuration mechanism has to work over the tunnel, and the + underlying tunneling mechanism could be implementing NAT traversal. + The tunnel server assumes the role of a relay (both for DHCP and + Well-known anycast addresses approaches). + + RA-based mechanism is relatively straightforward in its operation, + assuming the tunnel server is also the IPv6 router emitting RAs. + Well-known anycast addresses approach seems also simple in + operation across the tunnel, but the deployment model using Well- + known anycast addresses in a tunneled environment is unclear or not + well understood. + +5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP + + This is similar to a typical IPv4 home user scenario, where DNS + configuration parameters are obtained using DHCP. Except that + Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the + DHCP server is stateful (maintains the state for clients). + + + + +Jeong, et al. Expires - January 2005 [Page 18] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + +5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP + + This is similar to Case B. If a gateway provides IPv6 connectivity + by managing tunnels, then it is also supposed to provide access to + an RDNSS. Like this, the tunnel for IPv6 connectivity originates + from the dual-stack gateway instead of the host. + +5.4.4 Case D: A gateway connected to an IPv6-only ISP + + This is similar to Case B. + +6. Security Considerations + + As security requirements depend solely on applications and are + different application by application, there can be no generic + requirement defined at higher IP or lower application layer of DNS. + + However, it should be noted that cryptographic security requires + configured secret information that full autoconfiguration and + cryptographic security are mutually exclusive. People insisting on + secure full autoconfiguration will get false security, false + autoconfiguration or both. + + In some deployment scenario [19], where cryptographic security is + required for applications, secret information for the cryptographic + security is preconfigured through which application specific + configuration data, including those for DNS, can be securely + configured. It should be noted that if applications requiring + cryptographic security depend on DNS, the applications also require + cryptographic security to DNS. Therefore, the full auto- + configuration of DNS is not acceptable. + + However, with full autoconfiguration, weaker but still reasonable + security is being widely accepted and will continue to be + acceptable. That is, with full autoconfiguration, which means + there is no cryptographic security for the autoconfiguration, it is + already assumed that local environment is secure enough that + information from local autoconfiguration server has acceptable + security even without cryptographic security. Thus, communication + between a local DNS client and a local DNS server has the + acceptable security. + + For security considerations of each approach, refer to the + corresponding drafts [5]-[9]. + +7. Acknowledgements + + + + +Jeong, et al. Expires - January 2005 [Page 19] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + This draft has greatly benefited from inputs by David Meyer, Rob + Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, + Christian Huitema, and Thomas Narten. The authors appreciate their + contribution. + +8. Normative References + + [1] S. Bradner, "Intellectual Property Rights in IETF Technology", + RFC 3668, February 2004. + + [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February + 2004. + + [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for + IP Version 6 (IPv6)", RFC 2461, December 1998. + + [4] S. Thomson and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [5] R. Droms et al., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [6] R. Droms, "Stateless Dynamic Host Configuration Protocol + (DHCP) Service for IPv6", RFC 3736, April 2004. + + [7] R. Droms et al., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December + 2003. + +9. Informative References + + [8] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS + Discovery based on Router Advertisement", draft-jeong-dnsop- + ipv6-dns-discovery-02.txt, July 2004. + + [9] M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta- + preconfigured-dns-01.txt, February 2004. + + [10] S. Venaas and T. Chown, "Lifetime Option for DHCPv6", draft- + ietf-dhc-lifetime-00.txt, March 2004. + + [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + + + +Jeong, et al. Expires - January 2005 [Page 20] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6 + into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis- + 02.txt, April 2004. + + [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft- + ietf-send-ndopt-05.txt, April 2004. + + [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages", + RFC 3118, June 2001. + + [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", draft- + ietf-v6ops-ent-scenarios-01.txt, February 2004. + + [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host + Configuration Protocol (DHCP) version 6", RFC 3633, December + 2003. + + [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP + Standards", RFC 3314, September 2002. + + [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks", + RFC 3574, August 2003. + + [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP + Networks", draft-ietf-v6ops-3gpp-analysis-09.txt, March 2004. + + [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); + Service description; Stage 2 (Release 5)", December 2002. + + [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 + specification; Core network protocols; Stage 3 (Release 5)", + June 2003. + + [23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering + Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless- + dhcpv6-renumbering-00.txt, March 2004. + + [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition + Scenarios", RFC 3750, April 2004. + +10. Authors' Addresses + + Jaehoon Paul Jeong, Editor + ETRI / PEC + 161 Gajeong-dong, Yuseong-gu + Daejeon 305-350 + Korea + + + +Jeong, et al. Expires - January 2005 [Page 21] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + Phone: +82 42 860 1664 + Fax: +82 42 861 5404 + EMail: paul@etri.re.kr + + Ralph Droms + Cisco Systems + 1414 Massachusetts Ave. + Boxboro, MA 01719 + USA + + Phone: +1 978 936 1674 + EMail: rdroms@cisco.com + + Robert M. Hinden + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + USA + + Phone: +1 650 625 2004 + EMail: bob.hinden@nokia.com + + Ted Lemon + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94043 + USA + + EMail: Ted.Lemon@nominum.com + + Masataka Ohta + Graduate School of Information Science and Engineering + Tokyo Institute of Technology + 2-12-1, O-okayama, Meguro-ku + Tokyo 152-8552 + Japan + + Phone: +81 3 5734 3299 + Fax: +81 3 5734 3299 + EMail: mohta@necom830.hpcl.titech.ac.jp + + Soohong Daniel Park + Mobile Platform Laboratory, SAMSUNG Electronics + 416, Maetan-3dong, Paldal-gu, Suwon + Gyeonggi-Do + Korea + + Phone: +82 31 200 4508 + + +Jeong, et al. Expires - January 2005 [Page 22] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + EMail: soohong.park@samsung.com + + Suresh Satapati + Cisco Systems, Inc. + San Jose, CA 95134 + USA + + EMail: satapati@cisco.com + + Juha Wiljakka + Nokia + Visiokatu 3 + FIN-33720 TAMPERE + Finland + + Phone: +358 7180 48372 + EMail: juha.wiljakka@nokia.com + +Intellectual Property Statement + + The following intellectual property notice is copied from RFC3668, + Section 5. + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology described + in this document or the extent to which any license under such + rights might or might not be available; nor does it represent that + it has made any independent effort to identify any such rights. + Information on the procedures with respect to rights in RFC + documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Full Copyright Statement + + + + +Jeong, et al. Expires - January 2005 [Page 23] + +Internet-Draft IPv6 Host Configuration of DNS Server July 2004 + + + The following copyright notice is copied from RFC3667, Section 5.4. + It describes the applicable copyright for this document. + + Copyright (C) The Internet Society (2004). This document is + subject to the rights, licenses and restrictions contained in BCP + 78, and except as set forth therein, the authors retain all their + rights. + + This document and the information contained herein are provided on + an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong, et al. Expires - January 2005 [Page 24] + + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt deleted file mode 100644 index 280c2f2d9a..0000000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt +++ /dev/null @@ -1,1233 +0,0 @@ - - -DNS Operations WG A. Durand -Internet-Draft SUN Microsystems, Inc. -Expires: July 1, 2004 J. Ihren - Autonomica - P. Savola - CSC/FUNET - Jan 2004 - - - Operational Considerations and Issues with IPv6 DNS - draft-ietf-dnsop-ipv6-dns-issues-04.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 1, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This memo presents operational considerations and issues with IPv6 - Domain Name System (DNS), including a summary of special IPv6 - addresses, documentation of known DNS implementation misbehaviour, - recommendations and considerations on how to perform DNS naming for - service provisioning and for DNS resolver IPv6 support, - considerations for DNS updates for both the forward and reverse - trees, and miscellaneous issues. This memo is aimed to include a - summary of information about IPv6 DNS considerations for those who - have experience with IPv4 DNS. - - - -Durand, et al. Expires July 1, 2004 [Page 1] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . . . 3 - 1.2 Independence of DNS Transport and DNS Records . . . . . . . . 3 - 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . . . 4 - 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 4 - 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . . . 4 - 2.2 Privacy (RFC3041) Address . . . . . . . . . . . . . . . . . . 4 - 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 5 - 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . . . 5 - 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . . . 6 - 4. Recommendations for Service Provisioning using DNS . . . . . . 6 - 4.1 Use of Service Names instead of Node Names . . . . . . . . . . 6 - 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . . . 7 - 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . . . 7 - 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . . . 8 - 4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments . . . . . . 8 - 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . . . 9 - 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 9 - 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . . . 9 - 5.2 Recursive DNS Resolver Discovery . . . . . . . . . . . . . . . 11 - 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . . . 11 - 6. Considerations about Forward DNS Updating . . . . . . . . . . 11 - 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 12 - 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 7. Considerations about Reverse DNS Updating . . . . . . . . . . 13 - 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . . . 13 - 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 14 - 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . . . 14 - 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . . . 15 - 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 15 - 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . . . 15 - 8.2 Renumbering Procedures and Applications' Use of DNS . . . . . 15 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - Normative References . . . . . . . . . . . . . . . . . . . . . 16 - Informative References . . . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 - A. Site-local Addressing Considerations for DNS . . . . . . . . . 19 - Intellectual Property and Copyright Statements . . . . . . . . 21 - - - - - - - - -Durand, et al. Expires July 1, 2004 [Page 2] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - -1. Introduction - - This memo presents operational considerations and issues with IPv6 - DNS; it is meant to be an extensive summary and a list of pointers - for more information about IPv6 DNS considerations for those with - experience with IPv4 DNS. - - The first section gives a brief overview of how IPv6 addresses and - names are represented in the DNS, how transport protocols and - resource records (don't) relate, and what IPv4/IPv6 name space - fragmentation means and how to avoid it; all of these are described - at more length in other documents. - - The second section summarizes the special IPv6 address types and how - they relate to DNS. The third section describes observed DNS - implementation misbehaviours which have a varying effect on the use - of IPv6 records with DNS. The fourth section lists recommendations - and considerations for provisioning services with DNS. The fifth - section in turn looks at recommendations and considerations about - providing IPv6 support in the resolvers. The sixth and seventh - sections describe considerations with forward and reverse DNS - updates, respectively. The eighth section introduces several - miscellaneous IPv6 issues relating to DNS for which no better place - has been found in this memo. Appendix A looks briefly at the - requirements for site-local addressing. - -1.1 Representing IPv6 Addresses in DNS Records - - In the forward zones, IPv6 addresses are represented using AAAA - records. In the reverse zones, IPv6 address are represented using - PTR records in the nibble format under the ip6.arpa. -tree. See [1] - for more about IPv6 DNS usage, and [2] or [4] for background - information. - - In particular one should note that the use of A6 records, DNAME - records in the reverse tree, or Bitlabels in the reverse tree is not - recommended [2]. - -1.2 Independence of DNS Transport and DNS Records - - DNS has been designed to present a single, globally unique name space - [6]. This property should be maintained, as described here and in - Section 1.3. - - In DNS, the IP version used to transport the queries and responses is - independent of the records being queried: AAAA records can be queried - over IPv4, and A records over IPv6. The DNS servers must not make any - assumptions about what data to return for Answer and Authority - - - -Durand, et al. Expires July 1, 2004 [Page 3] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - sections. - - However, there is some debate whether the addresses in Additional - section could be selected or filtered using hints obtained from which - transport was being used; this has some obvious problems because in - many cases the transport protocol does not correlate with the - requests, and because a "bad" answer is in a way worse than no answer - at all (consider the case where the client is led to believe that a - name received in the additional record does not have any AAAA records - to begin with). - - As stated in [1]: - - The IP protocol version used for querying resource records is - independent of the protocol version of the resource records; e.g., - IPv4 transport can be used to query IPv6 records and vice versa. - - -1.3 Avoiding IPv4/IPv6 Name Space Fragmentation - - To avoid the DNS name space from fragmenting into parts where some - parts of DNS are only visible using IPv4 (or IPv6) transport, the - recommendation is to always keep at least one authoritative server - IPv4-enabled, and to ensure that recursive DNS servers support IPv4. - See DNS IPv6 transport guidelines [3] for more information. - -2. DNS Considerations about Special IPv6 Addresses - - There are a couple of IPv6 address types which are somewhat special; - these are considered here. - -2.1 Limited-scope Addresses - - The IPv6 addressing architecture [5] includes two kinds of local-use - addresses: link-local (fe80::/10) and site-local (fec0::/10). The - site-local addresses are being deprecated [7], and are only discussed - in Appendix A. - - Link-local addresses should never be published in DNS, because they - have only local (to the connected link) significance [8]. - -2.2 Privacy (RFC3041) Address - - Privacy addresses (RFC3041 [9]) use a random number as the interface - identifier. Publishing DNS records relating to such addresses would - defeat the purpose of the mechanism and is not recommended. If - absolutely necessary, a mapping could be made to some - non-identifiable name, as described in [9]. - - - -Durand, et al. Expires July 1, 2004 [Page 4] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - -2.3 6to4 Addresses - - 6to4 [10] specifies an automatic tunneling mechanism which maps a - public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. - Providing reverse DNS delegation path for such addresses is a - challenge. Note that similar difficulties don't surface with the - other automatic tunneling mechanisms (in particular, providing - reverse DNS information for Teredo [11] hosts whose address includes - the UDP port of the NAT binding does not seem reasonable). - - If the reverse DNS population would be desirable (see Section 7.1 for - applicability), there are a number of ways to tackle the delegation - path problem [12], some more applicable than the others. - - The main proposal [13] has been to allocate 2.0.0.2.ip6.arpa. to RIRs - and let them do subdelegations in accordance to the delegations of - the respective IPv4 address space. This has a major practical - drawback: those ISPs and IPv4 address space holders where 6to4 is - being used do not, in general, provide any IPv6 services -- as - otherwise, most people would not have to use 6to4 to begin with -- - and it is improbable that the reverse delegation chain would be - completed either. In most cases, creating such delegation chains - might just lead to latencies caused by lookups for (almost always) - non-existent DNS records. - -3. Observed DNS Implementation Misbehaviour - - Several classes of misbehaviour in DNS servers, load-balancers and - resolvers have been observed. Most of these are rather generic, not - only applicable to IPv6 -- but in some cases, the consequences of - this misbehaviour are extremely severe in IPv6 environments and - deserve to be mentioned. - -3.1 Misbehaviour of DNS Servers and Load-balancers - - There are several classes of misbehaviour in certain DNS servers and - load-balancers which have been noticed and documented [14]: some - implementations silently drop queries for unimplemented DNS records - types, or provide wrong answers to such queries (instead of a proper - negative reply). While typically these issues are not limited to - AAAA records, the problems are aggravated by the fact that AAAA - records are being queried instead of (mainly) A records. - - The problems are serious because when looking up a DNS name, typical - getaddrinfo() implementations, with AF_UNSPEC hint given, first try - to query the AAAA records of the name, and after receiving a - response, query the A records. This is done in a serial fashion -- if - the first query is never responded to (instead of properly returning - - - -Durand, et al. Expires July 1, 2004 [Page 5] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - a negative answer), significant timeouts will occur. - - In consequence, this is an enormous problem for IPv6 deployments, and - in some cases, IPv6 support in the software has even been disabled - due to these problems. - - The solution is to fix or retire those misbehaving implementations, - but that is likely not going to be effective. There are some - possible ways to mitigate the problem, e.g. by performing the lookups - somewhat in parallel and reducing the timeout as long as at least one - answer has been received; but such methods remain to be investigated; - slightly more on this is included in Section 5. - -3.2 Misbehaviour of DNS Resolvers - - Several classes of misbehaviour have also been noticed in DNS - resolvers [15]. However, these do not seem to directly impair IPv6 - use, and are only referred to for completeness. - -4. Recommendations for Service Provisioning using DNS - - When names are added in the DNS to facilitate a service, there are - several general guidelines to consider to be able to do it as - smoothly as possible. - -4.1 Use of Service Names instead of Node Names - - When a node includes multiple services, one should keep them - logically separate in the DNS. This can be done by the use of - service names instead of node names (or, "hostnames"). - - For example, assume a node named "pobox.example.com" provides both - SMTP and IMAP service. Instead of configuring the MX records to - point at "pobox.example.com", and configuring the mail clients to - look up the mail via IMAP from "pobox.example.com", one should use - e.g. "smtp.example.com" for SMTP (for both message submission and - mail relaying between SMTP servers) and "imap.example.com" for IMAP. - Note that in the specific case of SMTP relaying, the server itself - must typically also be configured to know all its names to ensure - loops do not occur. DNS can provide a layer of indirection between - service names and where the service actually is, and using which - addresses. - - This is a good practice with IPv4 as well, because it provides more - flexibility and enables easier migration of services from one host to - another. A specific reason why this is relevant for IPv6 is that the - different services may have a different level of IPv6 support -- that - is, one node providing multiple services might want to enable just - - - -Durand, et al. Expires July 1, 2004 [Page 6] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - one service to be IPv6-visible while keeping some others as - IPv4-only. Using service names enables more flexibility with - different IP versions as well. - -4.2 Separate vs the Same Service Names for IPv4 and IPv6 - - The service naming can be achieved in basically two ways: when a - service is named "service.example.com" for IPv4, the IPv6-enabled - service could be either added to "service.example.com", or added - separately to a sub-domain, like, "service.ipv6.example.com". - - Both methods have different characteristics. Using a sub-domain - allows for easier service piloting, minimizing the disturbance to the - "regular" users of IPv4 service; however, the service would not be - used without explicitly asking for it (or, within a restricted - network, modifying the DNS search path) -- so it will not actually be - used that much. Using the same service name is the "long-term" - solution, but may degrade performance for those clients whose IPv6 - performance is lower than IPv4, or does not work as well (see the - next subsection for more). - - In most cases, it makes sense to pilot or test a service using - separate service names, and move to the use of the same name when - confident enough that the service level will not degrade for the - users unaware of IPv6. - -4.3 Adding the Records Only when Fully IPv6-enabled - - The recommendation is that AAAA records for a service should not be - added to the DNS until all of following are true: - - 1. The address is assigned to the interface on the node. - - 2. The address is configured on the interface. - - 3. The interface is on a link which is connected to the IPv6 - infrastructure. - - In addition, if the AAAA record is added for the node, instead of - service as recommended, all the services of the node should be - IPv6-enabled prior to adding the resource record. - - For example, if an IPv6 node is isolated from an IPv6 perspective - (e.g., it is not connected to IPv6 Internet) constraint #3 would mean - that it should not have an address in the DNS. - - Consider the case of two dual-stack nodes, which both have IPv6 - enabled, but the server does not have (global) IPv6 connectivity. As - - - -Durand, et al. Expires July 1, 2004 [Page 7] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - the client looks up the server's name, only A records are returned - (if the recommendations above are followed), and no IPv6 - communication, which would have been unsuccessful, is even attempted. - - The issues are not always so black-and-white. Usually it's important - if the service offered using both protocols is of roughly equal - quality, using the appropriate metrics for the service (e.g., - latency, throughput, low packet loss, general reliability, etc.) -- - this is typically very important especially for interactive or - real-time services. In many cases, the quality of IPv6 connectivity - is not yet equal to that of IPv4, at least globally -- this has to be - taken into consideration when enabling services [16]. - -4.4 The Use of TTL for IPv4 and IPv6 RRs - - The behaviour of DNS caching when different TTL values are used for - different records of the same name requires explicit discussion. For - example, let's consider a part of a zone: - - example.com. 300 IN MX foo.example.com. - foo.example.com. 300 IN A 192.0.2.1 - foo.example.com. 100 IN AAAA 2001:db8::1 - - Now, when a caching resolver asks for the MX record of example.com, - it gets both A and AAAA records of foo.example.com. Then, after 100 - seconds, the AAAA record is removed from the cache because its TTL - expired. Now, subsequent queries only result in the cache returning - the A record; after 200 seconds the A record is purged as well. So, - in this particular case, there is a window of 200 seconds when - incomplete information is returned from the cache. - - Therefore, when the same name refers to both A and AAAA records, - these records should have the same TTL. Otherwise, the caches may - return incomplete information about the queried names. More issues - with caching and A/AAAA records is presented in the next section. - -4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments - - In the previous section, we discussed the effect of impartial data - returned from the caches when the TTLs are not kept the same. Now, - we present another problem highlighted in the mixed IPv4/IPv6 - environments. - - Consider the case where the query is so long or the number of the - additional ("glue") records is so high that the response must either - be truncated (leading to a retry with TCP) or some of the additional - data removed from the reply. Further, resource record sets are never - "broken up", so if a name has 4 A records and 5 AAAA records, you can - - - -Durand, et al. Expires July 1, 2004 [Page 8] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - either return all 9, all 4 A records, all 5 AAAA records or nothing. - - In the case of too much additional data, it might be tempting to not - return the AAAA records if the transport for DNS query was IPv4, or - not return the A records, if the transport was IPv6. However, this - breaks the model of independence of DNS transport and resource - records, as noted in Section 1.2. - - This temptation would have significant problems in multiple areas. - Remember that often the end-node, which will be using the records, is - not the same one as the node requesting them from the authorative DNS - server (or even a caching resolver). So, whichever version the - requestor ("the middleman") uses makes no difference to the ultimate - user of the records. This might result in e.g., inappropriately - returning A records to an IPv6-only node, going through a - translation, or opening up another IP-level session (e.g., a PDP - context [31]). - - The problem of too much additional data seems to be an operational - one: the zone administrator entering too many records which will be - returned either truncated or impartial to the users. A protocol fix - for this is using EDNS0 [32] to signal the capacity for larger UDP - packet sizes, pushing up the relevant threshold. The operational fix - for this is having the DNS server implementations return a warning - when the administrators create the zones which would result in too - much additional data being returned. - -4.6 IPv6 Transport Guidelines for DNS Servers - - As described in Section 1.3 and [3], there should continue to be at - least one authorative IPv4 DNS server for every zone, even if the - zone has only IPv6 records. (Note that obviously, having more servers - with robust connectivity would be preferable, but this is the minimum - recommendation; also see [17].) - -5. Recommendations for DNS Resolver IPv6 Support - - When IPv6 is enabled on a node, there are several things to consider - to ensure that the process is as smooth as possible. - -5.1 DNS Lookups May Query IPv6 Records Prematurely - - The system library that implements the getaddrinfo() function for - looking up names is a critical piece when considering the robustness - of enabling IPv6; it may come in basically three flavours: - - 1. The system library does not know whether IPv6 has been enabled in - the kernel of the operating system: it may start looking up AAAA - - - -Durand, et al. Expires July 1, 2004 [Page 9] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - records with getaddrinfo() and AF_UNSPEC hint when the system is - upgraded to a system library version which supports IPv6. - - 2. The system library might start to perform IPv6 queries with - getaddrinfo() only when IPv6 has been enabled in the kernel. - However, this does not guarantee that there exists any useful - IPv6 connectivity (e.g., the node could be isolated from the - other IPv6 networks, only having link-local addresses). - - 3. The system library might implement a toggle which would apply - some heuristics to the "IPv6-readiness" of the node before - starting to perform queries; for example, it could check whether - only link-local IPv6 address(es) exists, or if at least one - global IPv6 address exists. - - First, let us consider generic implications of unnecessary queries - for AAAA records: when looking up all the records in the DNS, AAAA - records are typically tried first, and then A records. These are - done in serial, and the A query is not performed until a response is - received to the AAAA query. Considering the misbehaviour of DNS - servers and load-balancers, as described in Section 3.1, the look-up - delay for AAAA may incur additional unnecessary latency, and - introduce a component of unreliability. - - One option here could be to do the queries partially in parallel; for - example, if the final response to the AAAA query is not received in - 0.5 seconds, start performing the A query while waiting for the - result (immediate parallelism might be unoptimal without information - sharing between the look-up threads, as that would probably lead to - duplicate non-cached delegation chain lookups). - - An additional concern is the address selection, which may, in some - circumstances, prefer AAAA records over A records, even when the node - does not have any IPv6 connectivity [18]. In some cases, the - implementation may attempt to connect or send a datagram on a - physical link [19], incurring very long protocol timeouts, instead of - quickly failing back to IPv4. - - Now, we can consider the issues specific to each of the three - possibilities: - - In the first case, the node performs a number of completely useless - DNS lookups as it will not be able to use the returned AAAA records - anyway. (The only exception is where the application desires to know - what's in the DNS, but not use the result for communication.) One - should be able to disable these unnecessary queries, for both latency - and reliability reasons. However, as IPv6 has not been enabled, the - connections to IPv6 addresses fail immediately, and if the - - - -Durand, et al. Expires July 1, 2004 [Page 10] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - application is programmed properly, the application can fall - gracefully back to IPv4 [20]. - - The second case is similar to the first, except it happens to a - smaller set of nodes when IPv6 has been enabled but connectivity has - not been provided yet; similar considerations apply, with the - exception that IPv6 records, when returned, will be actually tried - first which may typically lead to long timeouts. - - The third case is a bit more complex: optimizing away the DNS lookups - with only link-locals is probably safe (but may be desirable with - different lookup services which getaddrinfo() may support), as the - link-locals are typically automatically generated when IPv6 is - enabled, and do not indicate any form of IPv6 connectivity. That - is, performing DNS lookups only when a non-link-local address has - been configured on any interface could be beneficial -- this would be - an indication that either the address has been configured either from - a router advertisement, DHCPv6, or manually. Each would indicate at - least some form of IPv6 connectivity, even though there would not be - guarantees of it. - - These issues should be analyzed at more depth, and the fixes found - consensus on, perhaps in a separate document. - -5.2 Recursive DNS Resolver Discovery - - Recursive IPv6 DNS resolver discovery is a subject of active debate - at the moment: the main proposed mechanisms include the use of - well-known addresses [21], the use of Router Advertisements to convey - the information [22], and using DHCPv6 (or the stateless subset of it - [23]) for DNS resolver configuration. No consensus has been reached - yet. - - Note that IPv6 DNS resolver discovery, while an important topic, is - not required for dual-stack nodes in dual-stack networks: IPv6 DNS - records can very well be queried over IPv4 as well. - -5.3 IPv6 Transport Guidelines for Resolvers - - As described in Section 1.3 and [3], the recursive resolvers should - be IPv4-only or dual-stack to be able to reach any IPv4-only DNS - server. Note that this requirement is also fulfilled by an IPv6-only - stub resolver pointing to a dual-stack recursive DNS resolver. - -6. Considerations about Forward DNS Updating - - While the topic how to enable updating the forward DNS, i.e., the - mapping from names to the correct new addresses, is not specific to - - - -Durand, et al. Expires July 1, 2004 [Page 11] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - IPv6, it bears thinking about especially due to adding Stateless - Address Autoconfiguration [24] to the mix. - - Typically forward DNS updates are more manageable than doing them in - the reverse DNS, because the updater can, typically, be assumed to - "own" a certain DNS name -- and we can create a form of security - association with the DNS name and the node allowed to update it to - point to a new address. - - A more complex form of DNS updates -- adding a whole new name to a - DNS zone, instead of updating an existing name -- is considered - out-of-scope: this is not an IPv6-specific problem, and one still - being explored. - -6.1 Manual or Custom DNS Updates - - The DNS mappings can be maintained by hand, in a semi-automatic - fashion or by running non-standardized protocols. These are not - considered at more length in this memo. - -6.2 Dynamic DNS - - Dynamic DNS updates (DDNS) [25][26] is a standardized mechanism for - dynamically updating the DNS. It works equally well with stateless - address autoconfiguration (SLAAC), DHCPv6 or manual address - configuration. The only (minor) twist is that with SLAAC, the DNS - server cannot tie the authentication of the user to the IP address, - and stronger mechanisms must be used. Actually, relying on IP - addresses for Dynamic DNS is rather insecure at best, so this is - probably not a significant problem (but requires that the - authorization keying will be explicitly configured). - - Note that with DHCP, it is also possible that the DHCP server updates - the DNS, not the host. The host might only indicate in the DHCP - exchange which hostname it would prefer, and the DHCP server would - make the appropriate updates. Nonetheless, while this makes setting - up a secure channel between the updater and the DNS server easier, it - does not help much with "content" security, i.e., whether the - hostname was acceptable -- if the DNS server does not include - policies, they must be included in the DHCP server (e.g., a regular - host should not be able to state that its name is "www.example.com"). - - The nodes must somehow be configured with the information about the - servers where they will attempt to update their addresses, sufficient - security material for authenticating themselves to the server, and - the hostname they will be updating. Unless otherwise configured, the - first could be obtained by looking up the authorative name servers - for the hostname; the second must be configured explicitly unless one - - - -Durand, et al. Expires July 1, 2004 [Page 12] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - chooses to trust the IP address -based authentication (not a good - idea); and lastly, the nodename is typically pre-configured somehow - on the node, e.g. at install time. - - Care should be observed when updating the addresses not to use longer - TTLs for addresses than are preferred lifetimes for the - autoconfigured addresses, so that if the node is renumbered in a - managed fashion, the amount of stale DNS information is kept to the - minimum. Actually, the DNS TTL should be much shorter (e.g., a half - or a third) than the lifetime of an address; that way, the node can - start lowering the DNS TTL if it seems like the address has not be - renewed/refreshed in a while. Some discussion on how to manage the - DNS TTL is included in [28]. - -7. Considerations about Reverse DNS Updating - - Forward DNS updating is rather straightforward; reverse DNS is - significantly trickier especially with certain mechanisms. However, - first it makes sense to look at the applicability of reverse DNS in - the first place. - -7.1 Applicability of Reverse DNS - - Today, some applications use reverse DNS to either look up some hints - about the topological information associated with an address (e.g. - resolving web server access logs), or as a weak form of a security - check, to get a feel whether the user's network administrator has - "authorized" the use of the address (on the premises that adding a - reverse record for an address would signal some form of - authorization). - - One additional, maybe slightly more useful usage is ensuring the - reverse and forward DNS contents match and correspond to a configured - name or domain. As a security check, it is typically accompanied by - other mechanisms, such as a user/password login; the main purpose of - the DNS check is to weed out the majority of unauthorized users, and - if someone managed to bypass the checks, he would still need to - authenticate "properly". - - It is not clear whether it makes sense to require or recommend that - reverse DNS records be updated. In many cases, it would just make - more sense to use proper mechanisms for security (or topological - information lookup) in the first place. At minimum, the applications - which use it as a generic authorization (in the sense that a record - exists at all) should be modified as soon as possible to avoid such - lookups completely. - - The applicability is discussed at more length in [29]. - - - -Durand, et al. Expires July 1, 2004 [Page 13] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - -7.2 Manual or Custom DNS Updates - - Reverse DNS can of course be updated using manual or custom methods. - These are not further described here, except for one special case. - - One way to deploy reverse DNS would be to use wildcard records, for - example, by configuring one name for a subnet (/64) or a site (/48). - Naturally, such a name could not be verified from the forward DNS, - but would at least provide some form of "topological information" or - "weak authorization" if that is really considered to be useful. Note - that this is not actually updating the DNS as such, as the whole - point is to avoid DNS updates completely by manually configuring a - generic name. - -7.3 DDNS with Stateless Address Autoconfiguration - - Dynamic DNS with SLAAC is a bit complicated, but manageable with a - rather low form of security with some implementation. - - Every node on a link must then be allowed to insert its own reverse - DNS record in the reverse zone. However, in the typical case, there - can be no stronger form of authentication between the nodes and the - server than the source IP address (the user may roam to other - administrative domains as well, requiring updates to foreign DNS - servers), which might make attacks more lucrative. - - Moreover, the reverse zones must be cleaned up by some janitorial - process: the node does not typically know a priori that it will be - disconnected, and cannot send a DNS update using the correct source - address to remove a record. - - To insert or update the record, the node must discover the DNS server - to send the update to somehow, similar to as discussed in Section - 6.2. One way to automate this is looking up the DNS server - authoritative for the IP address being updated, but the security - material (unless the IP address -based authorization is trusted) must - also be established by some other means. - -7.4 DDNS with DHCP - - With DHCP, the reverse DNS name is typically already inserted to the - DNS that reflects to the name (e.g., "dhcp-67.example.com"). This is - pre-configured, and requires no updating. - - If a more explicit control is required, similar considerations as - with SLAAC apply, except for the fact that typically one must update - a reverse DNS record instead of inserting one -- due to a denser - address assignment policy -- and updating a record seems like a - - - -Durand, et al. Expires July 1, 2004 [Page 14] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - slightly more difficult thing to secure. - - Note that when using DHCP, either the host or the DHCP server could - perform the DNS updates; see the implications in Section 6.2. - -7.5 DDNS with Dynamic Prefix Delegation - - In cases where more than one address is being used and updated, one - should consider where the updated server resides. That is, whether - the prefixes have been delegated to a node in the local site, or - whether they reside elsewhere, e.g., at the ISP. The reverse DNS - updates are typically easier to manage if they can be done within a - single administrative entity -- and therefore, if a reverse DNS - delegation has been made, it may be easier to enable reverse DNS at - the site, e.g. by a wildcard record, or by some DNS update mechanism. - -8. Miscellaneous DNS Considerations - - This section describes miscellaneous considerations about DNS which - seem related to IPv6, for which no better place has been found in - this document. - -8.1 NAT-PT with DNS-ALG - - NAT-PT [27] DNS-ALG is a critical component (unless something - replacing that functionality is specified) which mangles A records to - look like AAAA records to the IPv6-only nodes. Numerous problems have - been identified with DNS-ALG [30]. - -8.2 Renumbering Procedures and Applications' Use of DNS - - One of the most difficult problems of systematic IP address - renumbering procedures [28] is that an application which looks up a - DNS name disregards information such as TTL, and uses the result - obtained from DNS as long as it happens to be stored in the memory of - the application. For applications which run for a long time, this - could be days, weeks or even months; some applications may be clever - enough to organize the data structures and functions in such a manner - that look-ups get refreshed now and then. - - While the issue appears to have a clear solution, "fix the - applications", practically this is not reasonable immediate advice; - the TTL information is not typically available in the APIs and - libraries (so, the advice becomes "fix the applications, APIs and - libraries"), and a lot more analysis is needed on how to practically - go about to achieve the ultimate goal of avoiding using the names - longer than expected. - - - - -Durand, et al. Expires July 1, 2004 [Page 15] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - -9. Acknowledgements - - Some recommendations (Section 4.3, Section 5.1) about IPv6 service - provisioning were moved here from [33] by Erik Nordmark and Bob - Gilligan. Havard Eidnes and Michael Patton provided useful feedback - and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark - Andrews helped in clarifying the issues regarding additional data and - the use of TTL. - -10. Security Considerations - - This document reviews the operational procedures for IPv6 DNS - operations and does not have security considerations in itself. - - However, it is worth noting that in particular with Dynamic DNS - Updates, security models based on the source address validation are - very weak and cannot be recommended. On the other hand, it should be - noted that setting up an authorization mechanism (e.g., a shared - secret, or public-private keys) between a node and the DNS server has - to be done manually, and may require quite a bit of time and - expertise. - - To re-emphasize which was already stated, reverse DNS checks provide - very weak security at best, and the only (questionable) - security-related use for them may be in conjunction with other - mechanisms when authenticating a user. - -Normative References - - [1] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October 2003. - - [2] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain, - "Representing Internet Protocol version 6 (IPv6) Addresses in - the Domain Name System (DNS)", RFC 3363, August 2002. - - [3] Durand, A. and J. Ihren, "DNS IPv6 transport operational - guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-01 (work - in progress), October 2003. - -Informative References - - [4] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August - 2001. - - [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - - - - -Durand, et al. Expires July 1, 2004 [Page 16] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - [6] Internet Architecture Board, "IAB Technical Comment on the - Unique DNS Root", RFC 2826, May 2000. - - [7] Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", draft-ietf-ipv6-deprecate-site-local-02 (work in - progress), November 2003. - - [8] Hazel, P., "IP Addresses that should never appear in the public - DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in - progress), February 2002. - - [9] Narten, T. and R. Draves, "Privacy Extensions for Stateless - Address Autoconfiguration in IPv6", RFC 3041, January 2001. - - [10] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via - IPv4 Clouds", RFC 3056, February 2001. - - [11] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", - draft-huitema-v6ops-teredo-00 (work in progress), June 2003. - - [12] Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work in - progress), October 2002. - - [13] Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa", - draft-ymbk-6to4-arpa-delegation-00 (work in progress), February - 2003. - - [14] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS - Queries for IPv6 Addresses", - draft-morishita-dnsop-misbehavior-against-aaaa-00 (work in - progress), June 2003. - - [15] Larson, M. and P. Barber, "Observed DNS Resolution - Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in - progress), June 2003. - - [16] Savola, P., "Moving from 6bone to IPv6 Internet", - draft-savola-v6ops-6bone-mess-01 (work in progress), November - 2002. - - [17] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and - Operation of Secondary DNS Servers", BCP 16, RFC 2182, July - 1997. - - [18] Roy, S., "Dual Stack IPv6 on by Default", - draft-ietf-v6ops-v6onbydefault-00 (work in progress), October - 2003. - - - - -Durand, et al. Expires July 1, 2004 [Page 17] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - [19] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered - Harmful", draft-ietf-v6ops-onlinkassumption-00 (work in - progress), October 2003. - - [20] Shin, M., "Application Aspects of IPv6 Transition", - draft-ietf-v6ops-application-transition-00 (work in progress), - December 2003. - - [21] Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-00 (work in progress), July 2003. - - [22] Jeong, J., "IPv6 DNS Discovery based on Router Advertisement", - draft-jeong-dnsop-ipv6-dns-discovery-00 (work in progress), - July 2003. - - [23] Droms, R., "Stateless DHCP Service for IPv6", - draft-ietf-dhc-dhcpv6-stateless-04 (work in progress), January - 2004. - - [24] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [25] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [26] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [27] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - - Protocol Translation (NAT-PT)", RFC 2766, February 2000. - - [28] Baker, F., "Procedures for Renumbering an IPv6 Network without - a Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in - progress), October 2003. - - [29] Senie, D., "Requiring DNS IN-ADDR Mapping", - draft-ietf-dnsop-inaddr-required-03 (work in progress), March - 2002. - - [30] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", - draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress), - February 2003. - - [31] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", - draft-ietf-v6ops-3gpp-analysis-07 (work in progress), October - 2003. - - - - -Durand, et al. Expires July 1, 2004 [Page 18] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - [32] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [33] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for - IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-01 (work in - progress), October 2003. - - -Authors' Addresses - - Alain Durand - SUN Microsystems, Inc. - 17 Network circle UMPL17-202 - Menlo Park, CA 94025 - USA - - EMail: Alain.Durand@sun.com - - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm - Sweden - - EMail: johani@autonomica.se - - - Pekka Savola - CSC/FUNET - - Espoo - Finland - - EMail: psavola@funet.fi - -Appendix A. Site-local Addressing Considerations for DNS - - As site-local addressing is being deprecated, and it is not yet clear - whether an addressing-based replacement (and which kind) is devised, - the considerations for site-local addressing are discussed briefly - here. - - The interactions with DNS come in two flavors: forward and reverse - DNS. - - To actually use site-local addresses within a site, this implies the - deployment of a "split-faced" or a fragmented DNS name space, for the - - - -Durand, et al. Expires July 1, 2004 [Page 19] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - zones internal to the site, and the outsiders' view to it. The - procedures to achieve this are not elaborated here. The implication - is that site-local addresses must not be published in the public DNS. - - To faciliate reverse DNS (if desired) with site-local addresses, the - stub resolvers must look for DNS information from the local DNS - servers, not e.g. starting from the root servers, so that the - site-local information may be provided locally. Note that the - experience private addresses in IPv4 has shown that the root servers - get loaded for requests for private address lookups in any. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires July 1, 2004 [Page 20] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Durand, et al. Expires July 1, 2004 [Page 21] - -Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires July 1, 2004 [Page 22] - - diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-08.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-08.txt new file mode 100644 index 0000000000..dd4709f93c --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-08.txt @@ -0,0 +1,1960 @@ +DNS Operations WG A. Durand +Internet-Draft SUN Microsystems, Inc. +Expires: January 16, 2005 J. Ihren + Autonomica + P. Savola + CSC/FUNET + July 18, 2004 + + + + Operational Considerations and Issues with IPv6 DNS + draft-ietf-dnsop-ipv6-dns-issues-08.txt + + +Status of this Memo + + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + This Internet-Draft will expire on January 16, 2005. + + +Copyright Notice + + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + +Abstract + + + This memo presents operational considerations and issues with IPv6 + Domain Name System (DNS), including a summary of special IPv6 + addresses, documentation of known DNS implementation misbehaviour, + recommendations and considerations on how to perform DNS naming for + + + + +Durand, et al. Expires January 16, 2005 [Page 1] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + service provisioning and for DNS resolver IPv6 support, + considerations for DNS updates for both the forward and reverse + trees, and miscellaneous issues. This memo is aimed to include a + summary of information about IPv6 DNS considerations for those who + have experience with IPv4 DNS. + + +Table of Contents + + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 + 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 + 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 + 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 + 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 + 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 + 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 + 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 + 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 + 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 + 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 + 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 + 4. Recommendations for Service Provisioning using DNS . . . . . . 8 + 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 + 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 + 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 + 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10 + 4.4.1 Description of Additional Data Scenarios . . . . . . . 10 + 4.4.2 Discussion of the Problems . . . . . . . . . . . . . . 11 + 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12 + 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 13 + 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 14 + 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14 + 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 15 + 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 16 + 6. Considerations about Forward DNS Updating . . . . . . . . . . 16 + 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17 + 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 17 + 7. Considerations about Reverse DNS Updating . . . . . . . . . . 18 + 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 18 + 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19 + 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 19 + 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20 + 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 21 + 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22 + 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 22 + 8.2 Renumbering Procedures and Applications' Use of DNS . . . 22 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 + + + + +Durand, et al. Expires January 16, 2005 [Page 2] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 + 11.2 Informative References . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 + A. Site-local Addressing Considerations for DNS . . . . . . . . . 28 + B. Issues about Additional Data or TTL . . . . . . . . . . . . . 28 + Intellectual Property and Copyright Statements . . . . . . . . 30 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires January 16, 2005 [Page 3] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + +1. Introduction + + + This memo presents operational considerations and issues with IPv6 + DNS; it is meant to be an extensive summary and a list of pointers + for more information about IPv6 DNS considerations for those with + experience with IPv4 DNS. + + + The purpose of this document is to give information about various + issues and considerations related to DNS operations with IPv6; it is + not meant to be a normative specification or standard for IPv6 DNS. + + + The first section gives a brief overview of how IPv6 addresses and + names are represented in the DNS, how transport protocols and + resource records (don't) relate, and what IPv4/IPv6 name space + fragmentation means and how to avoid it; all of these are described + at more length in other documents. + + + The second section summarizes the special IPv6 address types and how + they relate to DNS. The third section describes observed DNS + implementation misbehaviours which have a varying effect on the use + of IPv6 records with DNS. The fourth section lists recommendations + and considerations for provisioning services with DNS. The fifth + section in turn looks at recommendations and considerations about + providing IPv6 support in the resolvers. The sixth and seventh + sections describe considerations with forward and reverse DNS + updates, respectively. The eighth section introduces several + miscellaneous IPv6 issues relating to DNS for which no better place + has been found in this memo. Appendix A looks briefly at the + requirements for site-local addressing. + + +1.1 Representing IPv6 Addresses in DNS Records + + + In the forward zones, IPv6 addresses are represented using AAAA + records. In the reverse zones, IPv6 address are represented using + PTR records in the nibble format under the ip6.arpa. tree. See + [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] + for background information. + + + In particular one should note that the use of A6 records in the + forward tree or Bitlabels in the reverse tree is not recommended + [RFC3363]. Using DNAME records is not recommended in the reverse + tree in conjunction with A6 records; the document did not mean to + take a stance on any other use of DNAME records [RFC3364]. + + +1.2 Independence of DNS Transport and DNS Records + + + DNS has been designed to present a single, globally unique name space + [RFC2826]. This property should be maintained, as described here and + + + + +Durand, et al. Expires January 16, 2005 [Page 4] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + in Section 1.3. + + + In DNS, the IP version used to transport the queries and responses is + independent of the records being queried: AAAA records can be queried + over IPv4, and A records over IPv6. The DNS servers must not make + any assumptions about what data to return for Answer and Authority + sections based on the underlying transport used in a query. + + + However, there is some debate whether the addresses in Additional + section could be selected or filtered using hints obtained from which + transport was being used; this has some obvious problems because in + many cases the transport protocol does not correlate with the + requests, and because a "bad" answer is in a way worse than no answer + at all (consider the case where the client is led to believe that a + name received in the additional record does not have any AAAA records + to begin with). + + + As stated in [RFC3596]: + + + The IP protocol version used for querying resource records is + independent of the protocol version of the resource records; e.g., + IPv4 transport can be used to query IPv6 records and vice versa. + + + +1.3 Avoiding IPv4/IPv6 Name Space Fragmentation + + + To avoid the DNS name space from fragmenting into parts where some + parts of DNS are only visible using IPv4 (or IPv6) transport, the + recommendation is to always keep at least one authoritative server + IPv4-enabled, and to ensure that recursive DNS servers support IPv4. + See DNS IPv6 transport guidelines + [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information. + + +1.4 Query Type '*' and A/AAAA Records + + + QTYPE=* is typically only used for debugging or management purposes; + it is worth keeping in mind that QTYPE=* ("ANY" queries) only return + any available RRsets, not *all* the RRsets, because the caches do not + necessarily have all the RRsets and have no way of guaranteeing that + they have all the RRsets. Therefore, to get both A and AAAA records + reliably, two separate queries must be made. + + +2. DNS Considerations about Special IPv6 Addresses + + + There are a couple of IPv6 address types which are somewhat special; + these are considered here. + + + + + + +Durand, et al. Expires January 16, 2005 [Page 5] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + +2.1 Limited-scope Addresses + + + The IPv6 addressing architecture [RFC3513] includes two kinds of + local-use addresses: link-local (fe80::/10) and site-local (fec0::/ + 10). The site-local addresses are being deprecated + [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in + Appendix A. + + + Link-local addresses should never be published in DNS (whether in + forward or reverse tree), because they have only local (to the + connected link) significance + [I-D.ietf-dnsop-dontpublish-unreachable]. + + +2.2 Temporary Addresses + + + Temporary addresses defined in RFC3041 [RFC3041] (sometimes called + "privacy addresses") use a random number as the interface identifier. + Publishing (useful) DNS records relating to such addresses would + defeat the purpose of the mechanism and is not recommended. However, + it would still be possible to return a non-identifiable name (e.g., + the IPv6 address in hexadecimal format), as described in [RFC3041]. + + +2.3 6to4 Addresses + + + 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps + a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. + Providing reverse DNS delegation path for such addresses is not + straightforward and practically impossible. + + + If the reverse DNS population would be desirable (see Section 7.1 for + applicability), there are a number of ways to tackle the delegation + path problem [I-D.moore-6to4-dns], some more applicable than the + others. + + + The main proposal [I-D.huston-6to4-reverse-dns] aims to design an + autonomous reverse-delegation system that anyone being capable of + communicating using a specific 6to4 address would be able to set up a + reverse delegation to the corresponding 6to4 prefix. This could be + deployed by e.g., RIRs. This is a more practical solution, but may + have some scalability concerns. + + +2.4 Other Transition Mechanisms + + + 6to4, above, is mentioned as a case of an IPv6 transition mechanism + requiring special considerations. In general, mechanisms which + include a special prefix may need a custom solution; otherwise, for + example when IPv4 address is embedded as the suffix or not embedded + at all, special solutions are likely not needed. This is why only + + + + +Durand, et al. Expires January 16, 2005 [Page 6] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described. + + + Note that it does not seem feasible to provide reverse DNS with + another automatic tunneling mechanism, Teredo; this is because the + IPv6 address is based on the IPv4 address and UDP port of the current + NAT mapping which is likely to be relatively short-lived. + + +3. Observed DNS Implementation Misbehaviour + + + Several classes of misbehaviour in DNS servers, load-balancers and + resolvers have been observed. Most of these are rather generic, not + only applicable to IPv6 -- but in some cases, the consequences of + this misbehaviour are extremely severe in IPv6 environments and + deserve to be mentioned. + + +3.1 Misbehaviour of DNS Servers and Load-balancers + + + There are several classes of misbehaviour in certain DNS servers and + load-balancers which have been noticed and documented + [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations + silently drop queries for unimplemented DNS records types, or provide + wrong answers to such queries (instead of a proper negative reply). + While typically these issues are not limited to AAAA records, the + problems are aggravated by the fact that AAAA records are being + queried instead of (mainly) A records. + + + The problems are serious because when looking up a DNS name, typical + getaddrinfo() implementations, with AF_UNSPEC hint given, first try + to query the AAAA records of the name, and after receiving a + response, query the A records. This is done in a serial fashion -- + if the first query is never responded to (instead of properly + returning a negative answer), significant timeouts will occur. + + + In consequence, this is an enormous problem for IPv6 deployments, and + in some cases, IPv6 support in the software has even been disabled + due to these problems. + + + The solution is to fix or retire those misbehaving implementations, + but that is likely not going to be effective. There are some + possible ways to mitigate the problem, e.g. by performing the + lookups somewhat in parallel and reducing the timeout as long as at + least one answer has been received; but such methods remain to be + investigated; slightly more on this is included in Section 5. + + +3.2 Misbehaviour of DNS Resolvers + + + Several classes of misbehaviour have also been noticed in DNS + resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem + + + + +Durand, et al. Expires January 16, 2005 [Page 7] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + to directly impair IPv6 use, and are only referred to for + completeness. + + +4. Recommendations for Service Provisioning using DNS + + + When names are added in the DNS to facilitate a service, there are + several general guidelines to consider to be able to do it as + smoothly as possible. + + +4.1 Use of Service Names instead of Node Names + + + When a node includes multiple services which should not be + fate-sharing, or might support different IP versions, one should keep + them logically separate in the DNS. Using SRV records would avoid + these problems. Unfortunately, they are not sufficiently widely used + to be applicable in most cases. Hence an operation technique is to + use service names instead of node names (or, "hostnames"). This + operational technique is not specific to IPv6, but required to + understand the considerations described in Section 4.2 and Section + 4.3. + + + For example, assume a node named "pobox.example.com" provides both + SMTP and IMAP service. Instead of configuring the MX records to + point at "pobox.example.com", and configuring the mail clients to + look up the mail via IMAP from "pobox.example.com", one should use + e.g. "smtp.example.com" for SMTP (for both message submission and + mail relaying between SMTP servers) and "imap.example.com" for IMAP. + Note that in the specific case of SMTP relaying, the server itself + must typically also be configured to know all its names to ensure + loops do not occur. DNS can provide a layer of indirection between + service names and where the service actually is, and using which + addresses. (Obviously, when wanting to reach a specific node, one + should use the hostname rather than a service name.) + + + This is a good practice with IPv4 as well, because it provides more + flexibility and enables easier migration of services from one host to + another. A specific reason why this is relevant for IPv6 is that the + different services may have a different level of IPv6 support -- that + is, one node providing multiple services might want to enable just + one service to be IPv6-visible while keeping some others as + IPv4-only. Using service names enables more flexibility with + different IP versions as well. + + +4.2 Separate vs the Same Service Names for IPv4 and IPv6 + + + The service naming can be achieved in basically two ways: when a + service is named "service.example.com" for IPv4, the IPv6-enabled + service could be either added to "service.example.com", or added + + + + +Durand, et al. Expires January 16, 2005 [Page 8] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + separately under a different name, e.g., in a sub-domain, like, + "service.ipv6.example.com". + + + These two methods have different characteristics. Using a different + name allows for easier service piloting, minimizing the disturbance + to the "regular" users of IPv4 service; however, the service would + not be used transparently, without the user/application explicitly + finding it and asking for it -- which would be a disadvantage in most + cases. If the different name is under a sub-domain, if the services + are deployed within a restricted network (e.g., inside an + enterprise), it's possible to prefer them transparently, at least to + a degree, by modifying the DNS search path; however, this is a + suboptimal solution. Using the same service name is the "long-term" + solution, but may degrade performance for those clients whose IPv6 + performance is lower than IPv4, or does not work as well (see the + next subsection for more). + + + In most cases, it makes sense to pilot or test a service using + separate service names, and move to the use of the same name when + confident enough that the service level will not degrade for the + users unaware of IPv6. + + +4.3 Adding the Records Only when Fully IPv6-enabled + + + The recommendation is that AAAA records for a service should not be + added to the DNS until all of following are true: + + + 1. The address is assigned to the interface on the node. + + + 2. The address is configured on the interface. + + + 3. The interface is on a link which is connected to the IPv6 + infrastructure. + + + In addition, if the AAAA record is added for the node, instead of + service as recommended, all the services of the node should be + IPv6-enabled prior to adding the resource record. + + + For example, if an IPv6 node is isolated from an IPv6 perspective + (e.g., it is not connected to IPv6 Internet) constraint #3 would mean + that it should not have an address in the DNS. + + + Consider the case of two dual-stack nodes, which both have IPv6 + enabled, but the server does not have (global) IPv6 connectivity. As + the client looks up the server's name, only A records are returned + (if the recommendations above are followed), and no IPv6 + communication, which would have been unsuccessful, is even attempted. + + + + + +Durand, et al. Expires January 16, 2005 [Page 9] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + The issues are not always so black-and-white. Usually it's important + if the service offered using both protocols is of roughly equal + quality, using the appropriate metrics for the service (e.g., + latency, throughput, low packet loss, general reliability, etc.) -- + this is typically very important especially for interactive or + real-time services. In many cases, the quality of IPv6 connectivity + is not yet equal to that of IPv4, at least globally -- this has to be + taken into consideration when enabling services + [I-D.savola-v6ops-6bone-mess]. + + +4.4 Behaviour of Additional Data in IPv4/IPv6 Environments + + +4.4.1 Description of Additional Data Scenarios + + + Consider the case where the query name is so long, the number of the + additional records is so high, or for other reasons that the entire + response would not fit in a single UDP packet. In some cases, the + responder truncates the response with the TC bit being set (leading + to a retry with TCP), in order for the querier to get the entire + response later. + + + However, note that if too much additional information that is not + strictly necessary would be added, one should remove unnecessary + information instead of setting TC bit for this "courtesy" information + [RFC2181]. + + + Also notice that there are two kinds of additional data: + + + 1. glue, i.e., "critical" additional data; this must be included in + all scenarios, with all the RRsets as possible, and + + + 2. "courtesy" additional data; this could be sent in full, with only + a few RRsets, or with no RRsets, and can be fetched separately as + well, but at the cost of additional queries. This data should + never cause setting of the TC bit. + + + 3. The responding server can algorithmically determine which type + the additional data is by checking whether it's at or below a + zone cut. + + + Meanwhile, resource record sets (RRsets) are never "broken up", so if + a name has 4 A records and 5 AAAA records, you can either return all + 9, all 4 A records, all 5 AAAA records or nothing. Notice that for + the "critical" additional data getting all the RRsets can be + critical. + + + An example of the "courtesy" additional data is A/AAAA records in + conjunction of MX records as shown in Section 4.5; an example of the + + + + +Durand, et al. Expires January 16, 2005 [Page 10] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + "critical" additional data is shown below (where getting both the A + and AAAA RRsets is critical): + + + child.example.com. IN NS ns.child.example.com. + ns.child.example.com. IN A 192.0.2.1 + ns.child.example.com. IN AAAA 2001:db8::1 + + + When there is too much courtesy additional data, some or all of it + need to be removed; if some is left in the response, the issue is + which data should be retained. When there is too much critical + additional data, TC bit will have to be set, and some or all of it + need to be removed; if some is left in the response, the issue is + which data should be retained. + + + If the implementation decides to keep as much data as possible, it + might be tempting to use the transport of the DNS query as a hint in + either of these cases: return the AAAA records if the query was done + over IPv6, or return the A records, if the query was done over IPv4. + However, this breaks the model of independence of DNS transport and + resource records, as noted in Section 1.2. + + + It is worth remembering that often an end host which will be using + the records is not the same one as the node requesting them from the + authoritative DNS server (or even a caching resolver). So, whichever + version the requestor (e.g., a recursive server in the middle) uses + makes no difference to the ultimate user of the records, whose + transport capabilities might differ from those of the DNS server. + This might result in e.g., inappropriately returning A records to an + IPv6-only node, going through a translation, or opening up another + IP-level session (e.g., a PDP context + [I-D.ietf-v6ops-3gpp-analysis]). Therefore, at least in many + scenarios, it would be very useful if the information returned would + be consistent and complete -- or if that is not feasible, return no + misleading information but rather leave it to the client to query + again. + + +4.4.2 Discussion of the Problems + + + As noted above, the temptation for omitting additional data based on + the transport of the query would be problematic. In particular, + there appears to be little justification for that in the case of + "courtesy" data. However, with critical additional data, the + alternatives are either returning nothing (and requiring a retry with + TCP) or returning something (possibly obviating the need for a retry + with TCP). If the process for selecting "something" from the + critical data would otherwise be practically "flipping the coin" + between A and AAAA records, it could be argued that if one looked at + the transport of the query, it would have a larger possibility of + + + + +Durand, et al. Expires January 16, 2005 [Page 11] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + being right than just 50/50. In other words, if the returned + critical additional data would have to be selected somehow, using + something more sophisticated than a random process would seem + justifiable. + + + The problem of too much additional data seems to be an operational + one: the zone administrator entering too many records which will be + returned either truncated or missing some RRsets to the users. A + protocol fix for this is using EDNS0 [RFC2671] to signal the capacity + for larger UDP packet sizes, pushing up the relevant threshold. + Further, DNS server implementations should rather omit courtesy + additional data completely rather than including only some RRsets + [RFC2181]. An operational fix for this is having the DNS server + implementations return a warning when the administrators create the + zones which would result in too much additional data being returned. + Further, DNS server implementations should warn of or disallow such + zone configurations which are recursive or otherwise difficult to + manage by the protocol. + + + Additionally, to avoid the case where an application would not get an + address at all due to "courtesy" additional data being omitted, the + applications should be able to query the specific records of the + desired protocol, not just rely on getting all the required RRsets in + the additional section. + + +4.5 The Use of TTL for IPv4 and IPv6 RRs + + + In the previous section, we discussed a danger with queries, + potentially leading to omitting RRsets from the additional section; + this could happen to both critical and "courtesy" additional data. + This section discusses another problem with the latter, leading to + omitting RRsets in cached data, highlighted in the IPv4/IPv6 + environment. + + + The behaviour of DNS caching when different TTL values are used for + different RRsets of the same name requires explicit discussion. For + example, let's consider a part of a zone: + + + example.com. 300 IN MX foo.example.com. + foo.example.com. 300 IN A 192.0.2.1 + foo.example.com. 100 IN AAAA 2001:db8::1 + + + When a caching resolver asks for the MX record of example.com, it + gets back "foo.example.com". It may also get back either one or both + of the A and AAAA records in the additional section. So, there are + three cases about returning records for the MX in the additional + section: + + + + + +Durand, et al. Expires January 16, 2005 [Page 12] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + 1. We get back no A or AAAA RRsets: this is the simplest case, + because then we have to query which information is required + explicitly, guaranteeing that we get all the information we're + interested in. + + + 2. We get back all the RRsets: this is an optimization as there is + no need to perform more queries, causing lower latency. However, + it is impossible to guarantee that in fact we would always get + back all the records (the only way to ensure that is to send a + AAAA query for the name after getting the cached reply with A + records or vice versa); however, one could try to work in the + direction to try to ensure it as far as possible. + + + 3. We only get back A or AAAA RRsets even if both existed: this is + indistinguishable from the previous case, and problematic as + described in the previous section. + + + As the third case was considered in the previous section, we assume + we get back both A and AAAA records of foo.example.com, or the stub + resolver explicitly asks, in two separate queries, both A and AAAA + records. + + + After 100 seconds, the AAAA record is removed from the cache(s) + because its TTL expired. It would be useful for the caching + resolvers to discard the A record when the shorter TTL (in this case, + for the AAAA record) expires; this would avoid the situation where + there would be a window of 200 seconds when incomplete information is + returned from the cache. However, this is not mandated or mentioned + by the specification(s). + + + To simplify the situation, it might help to use the same TTL for all + the resource record sets referring to the same name, unless there is + a particular reason for not doing so. However, there are some + scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where + a different strategy is preferable. + + + Thus, applications that use the response should not rely on a + particular TTL configuration. For example, even if an application + gets a response that only has the A record in the example described + above, it should be still aware that there could be a AAAA record for + "foo.example.com". That is, the application should try to fetch the + missing records itself if it needs the record. + + +4.6 IPv6 Transport Guidelines for DNS Servers + + + As described in Section 1.3 and + [I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue to + be at least one authoritative IPv4 DNS server for every zone, even if + + + + +Durand, et al. Expires January 16, 2005 [Page 13] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + the zone has only IPv6 records. (Note that obviously, having more + servers with robust connectivity would be preferable, but this is the + minimum recommendation; also see [RFC2182].) + + +5. Recommendations for DNS Resolver IPv6 Support + + + When IPv6 is enabled on a node, there are several things to consider + to ensure that the process is as smooth as possible. + + +5.1 DNS Lookups May Query IPv6 Records Prematurely + + + The system library that implements the getaddrinfo() function for + looking up names is a critical piece when considering the robustness + of enabling IPv6; it may come in basically three flavours: + + + 1. The system library does not know whether IPv6 has been enabled in + the kernel of the operating system: it may start looking up AAAA + records with getaddrinfo() and AF_UNSPEC hint when the system is + upgraded to a system library version which supports IPv6. + + + 2. The system library might start to perform IPv6 queries with + getaddrinfo() only when IPv6 has been enabled in the kernel. + However, this does not guarantee that there exists any useful + IPv6 connectivity (e.g., the node could be isolated from the + other IPv6 networks, only having link-local addresses). + + + 3. The system library might implement a toggle which would apply + some heuristics to the "IPv6-readiness" of the node before + starting to perform queries; for example, it could check whether + only link-local IPv6 address(es) exists, or if at least one + global IPv6 address exists. + + + First, let us consider generic implications of unnecessary queries + for AAAA records: when looking up all the records in the DNS, AAAA + records are typically tried first, and then A records. These are + done in serial, and the A query is not performed until a response is + received to the AAAA query. Considering the misbehaviour of DNS + servers and load-balancers, as described in Section 3.1, the look-up + delay for AAAA may incur additional unnecessary latency, and + introduce a component of unreliability. + + + One option here could be to do the queries partially in parallel; for + example, if the final response to the AAAA query is not received in + 0.5 seconds, start performing the A query while waiting for the + result (immediate parallelism might be unoptimal without information + sharing between the look-up threads, as that would probably lead to + duplicate non-cached delegation chain lookups). + + + + + +Durand, et al. Expires January 16, 2005 [Page 14] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + An additional concern is the address selection, which may, in some + circumstances, prefer AAAA records over A records, even when the node + does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. + In some cases, the implementation may attempt to connect or send a + datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], + incurring very long protocol timeouts, instead of quickly failing + back to IPv4. + + + Now, we can consider the issues specific to each of the three + possibilities: + + + In the first case, the node performs a number of completely useless + DNS lookups as it will not be able to use the returned AAAA records + anyway. (The only exception is where the application desires to know + what's in the DNS, but not use the result for communication.) One + should be able to disable these unnecessary queries, for both latency + and reliability reasons. However, as IPv6 has not been enabled, the + connections to IPv6 addresses fail immediately, and if the + application is programmed properly, the application can fall + gracefully back to IPv4 [I-D.ietf-v6ops-application-transition]. + + + The second case is similar to the first, except it happens to a + smaller set of nodes when IPv6 has been enabled but connectivity has + not been provided yet; similar considerations apply, with the + exception that IPv6 records, when returned, will be actually tried + first which may typically lead to long timeouts. + + + The third case is a bit more complex: optimizing away the DNS lookups + with only link-locals is probably safe (but may be desirable with + different lookup services which getaddrinfo() may support), as the + link-locals are typically automatically generated when IPv6 is + enabled, and do not indicate any form of IPv6 connectivity. That is, + performing DNS lookups only when a non-link-local address has been + configured on any interface could be beneficial -- this would be an + indication that either the address has been configured either from a + router advertisement, DHCPv6 [RFC3315], or manually. Each would + indicate at least some form of IPv6 connectivity, even though there + would not be guarantees of it. + + + These issues should be analyzed at more depth, and the fixes found + consensus on, perhaps in a separate document. + + +5.2 Obtaining a List of DNS Recursive Resolvers + + + In scenarios where DHCPv6 is available, a host can discover a list of + DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" + option [RFC3646]. This option can be passed to a host through a + subset of DHCPv6 [RFC3736]. + + + + +Durand, et al. Expires January 16, 2005 [Page 15] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + The IETF is considering the development of alternative mechanisms for + obtaining the list of DNS recursive name servers when DHCPv6 is + unavailable or inappropriate. No decision about taking on this + development work has been reached as of this writing (Jul 2004) + [I-D.ietf-dnsop-ipv6-dns-configuration] + + + In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms + under consideration for development of dnsop WG include the use of + well-known addresses [I-D.ohta-preconfigured-dns], the use of Router + Advertisements to convey the information + [I-D.jeong-dnsop-ipv6-dns-discovery]. + + + Note that even though IPv6 DNS resolver discovery is a recommended + procedure, it is not required for dual-stack nodes in dual-stack + networks as IPv6 DNS records can be queried over IPv4 as well as + IPv6. Obviously, nodes which are meant to function without manual + configuration in IPv6-only networks must implement DNS resolver + discovery function. + + +5.3 IPv6 Transport Guidelines for Resolvers + + + As described in Section 1.3 and + [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers + should be IPv4-only or dual-stack to be able to reach any IPv4-only + DNS server. Note that this requirement is also fulfilled by an + IPv6-only stub resolver pointing to a dual-stack recursive DNS + resolver. + + +6. Considerations about Forward DNS Updating + + + While the topic how to enable updating the forward DNS, i.e., the + mapping from names to the correct new addresses, is not specific to + IPv6, it bears thinking about especially due to adding Stateless + Address Autoconfiguration [RFC2462] to the mix. + + + Typically forward DNS updates are more manageable than doing them in + the reverse DNS, because the updater can, typically, be assumed to + "own" a certain DNS name -- and we can create a form of security + relationship with the DNS name and the node allowed to update it to + point to a new address. + + + A more complex form of DNS updates -- adding a whole new name into a + DNS zone, instead of updating an existing name -- is considered out + of scope for this memo. Adding a new name in the forward zone is a + problem which is still being explored with IPv4, and IPv6 does not + seem to add much new in that area. + + + + + + +Durand, et al. Expires January 16, 2005 [Page 16] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + +6.1 Manual or Custom DNS Updates + + + The DNS mappings can be maintained by hand, in a semi-automatic + fashion or by running non-standardized protocols. These are not + considered at more length in this memo. + + +6.2 Dynamic DNS + + + Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized + mechanism for dynamically updating the DNS. It works equally well + with stateless address autoconfiguration (SLAAC), DHCPv6 or manual + address configuration. It is important to consider how each of these + behave if IP address-based authentication, instead of stronger + mechanisms [RFC3007], was used in the updates; manual addresses are + static and can be configured; DHCPv6 addresses could be reasonably + static or dynamic, depending on the deployment, and could or could + not be configured on the DNS server for the long term; SLAAC + addresses are typically stable for a long time, but could require + work to be configured and maintained. As relying on IP addresses for + Dynamic DNS is rather insecure at best, stronger authentication + should always be used; however, this requires that the authorization + keying will be explicitly configured using unspecified operational + methods. + + + Note that with DHCP it is also possible that the DHCP server updates + the DNS, not the host. The host might only indicate in the DHCP + exchange which hostname it would prefer, and the DHCP server would + make the appropriate updates. Nonetheless, while this makes setting + up a secure channel between the updater and the DNS server easier, it + does not help much with "content" security, i.e., whether the + hostname was acceptable -- if the DNS server does not include + policies, they must be included in the DHCP server (e.g., a regular + host should not be able to state that its name is "www.example.com"). + DHCP-initiated DDNS updates have been extensively described in + [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and + [I-D.ietf-dnsext-dhcid-rr]. + + + The nodes must somehow be configured with the information about the + servers where they will attempt to update their addresses, sufficient + security material for authenticating themselves to the server, and + the hostname they will be updating. Unless otherwise configured, the + first could be obtained by looking up the authoritative name servers + for the hostname; the second must be configured explicitly unless one + chooses to trust the IP address-based authentication (not a good + idea); and lastly, the nodename is typically pre-configured somehow + on the node, e.g. at install time. + + + Care should be observed when updating the addresses not to use longer + + + + +Durand, et al. Expires January 16, 2005 [Page 17] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + TTLs for addresses than are preferred lifetimes for the + autoconfigured addresses, so that if the node is renumbered in a + managed fashion, the amount of stale DNS information is kept to the + minimum. That is, if the preferred lifetime of an address expires, + the TTL of the record needs be modified unless it was already done + before the expiration. For better flexibility, the DNS TTL should be + much shorter (e.g., a half or a third) than the lifetime of an + address; that way, the node can start lowering the DNS TTL if it + seems like the address has not been renewed/refreshed in a while. + Some discussion on how an administrator could manage the DNS TTL is + included in [I-D.ietf-v6ops-renumbering-procedure]; this could be + applied to (smart) hosts as well. + + +7. Considerations about Reverse DNS Updating + + + Updating the reverse DNS zone may be difficult because of the split + authority over an address. However, first we have to consider the + applicability of reverse DNS in the first place. + + +7.1 Applicability of Reverse DNS + + + Today, some applications use reverse DNS to either look up some hints + about the topological information associated with an address (e.g. + resolving web server access logs), or as a weak form of a security + check, to get a feel whether the user's network administrator has + "authorized" the use of the address (on the premises that adding a + reverse record for an address would signal some form of + authorization). + + + One additional, maybe slightly more useful usage is ensuring the + reverse and forward DNS contents match (by looking up the pointer to + the name by the IP address from the reverse tree, and ensuring that + the records under the name in the forward tree also include the IP + address) and correspond to a configured name or domain. As a + security check, it is typically accompanied by other mechanisms, such + as a user/password login; the main purpose of the reverse+forward DNS + check is to weed out the majority of unauthorized users, and if + someone managed to bypass the checks, he would still need to + authenticate "properly". + + + It may also be desirable to store IPsec keying material corresponding + to an IP address to the reverse DNS, as justified and described in + [I-D.ietf-ipseckey-rr]. + + + It is not clear whether it makes sense to require or recommend that + reverse DNS records be updated. In many cases, it would just make + more sense to use proper mechanisms for security (or topological + information lookup) in the first place. At minimum, the applications + + + + +Durand, et al. Expires January 16, 2005 [Page 18] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + which use it as a generic authorization (in the sense that a record + exists at all) should be modified as soon as possible to avoid such + lookups completely. + + + The applicability is discussed at more length in + [I-D.ietf-dnsop-inaddr-required]. + + +7.2 Manual or Custom DNS Updates + + + Reverse DNS can of course be updated using manual or custom methods. + These are not further described here, except for one special case. + + + One way to deploy reverse DNS would be to use wildcard records, for + example, by configuring one name for a subnet (/64) or a site (/48). + As a concrete example, a site (or the site's ISP) could configure the + reverses of the prefix 2001:db8:f00::/48 to point to one name using a + wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR + site.example.com." Naturally, such a name could not be verified from + the forward DNS, but would at least provide some form of "topological + information" or "weak authorization" if that is really considered to + be useful. Note that this is not actually updating the DNS as such, + as the whole point is to avoid DNS updates completely by manually + configuring a generic name. + + +7.3 DDNS with Stateless Address Autoconfiguration + + + Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in + some regard, while being more difficult in another, as described + below. + + + The address space administrator decides whether the hosts are trusted + to update their reverse DNS records or not. If they are, a simple + address-based authorization is typically sufficient (i.e., check that + the DNS update is done from the same IP address as the record being + updated); stronger security can also be used [RFC3007]. If they + aren't allowed to update the reverses, no update can occur. (Such + address-based update authorization operationally requires that + ingress filtering [RFC3704] has been set up at the border of the site + where the updates occur, and as close to the updater as possible.) + + + Address-based authorization is simpler with reverse DNS (as there is + a connection between the record and the address) than with forward + DNS. However, when a stronger form of security is used, forward DNS + updates are simpler to manage because the host knows the record it's + updating, and can be assumed to have an association with the domain. + Note that the user may roam to different networks, and does not + necessarily have any association with the owner of that address space + -- so, assuming stronger form of authorization for reverse DNS + + + + +Durand, et al. Expires January 16, 2005 [Page 19] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + updates than an address association is generally unfeasible. + + + Moreover, the reverse zones must be cleaned up by an unspecified + janitorial process: the node does not typically know a priori that it + will be disconnected, and cannot send a DNS update using the correct + source address to remove a record. + + + A problem with defining the clean-up process is that it is difficult + to ensure that a specific IP address and the corresponding record are + no longer being used. Considering the huge address space, and the + unlikelihood of collision within 64 bits of the interface + identifiers, a process which would remove the record after no traffic + has been seen from a node in a long period of time (e.g., a month or + year) might be one possible approach. + + + To insert or update the record, the node must discover the DNS server + to send the update to somehow, similar to as discussed in Section + 6.2. One way to automate this is looking up the DNS server + authoritative (e.g., through SOA record) for the IP address being + updated, but the security material (unless the IP address-based + authorization is trusted) must also be established by some other + means. + + + One should note that Cryptographically Generated Addresses + [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of + treatment. CGAs are addresses where the interface identifier is + calculated from a public key, a modifier (used as a nonce), the + subnet prefix, and other data. Depending on the usage profile, CGAs + might or might not be changed periodically due to e.g., privacy + reasons. As the CGA address is not predicatable, a reverse record + can only reasonably be inserted in the DNS by the node which + generates the address. + + +7.4 DDNS with DHCP + + + With DHCPv4, the reverse DNS name is typically already inserted to + the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One + can assume similar practice may become commonplace with DHCPv6 as + well; all such mappings would be pre-configured, and would require no + updating. + + + If a more explicit control is required, similar considerations as + with SLAAC apply, except for the fact that typically one must update + a reverse DNS record instead of inserting one (if an address + assignment policy that reassigns disused addresses is adopted) and + updating a record seems like a slightly more difficult thing to + secure. However, it is yet uncertain how DHCPv6 is going to be used + for address assignment. + + + + +Durand, et al. Expires January 16, 2005 [Page 20] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + Note that when using DHCP, either the host or the DHCP server could + perform the DNS updates; see the implications in Section 6.2. + + + If disused addresses were to be reassigned, host-based DDNS reverse + updates would need policy considerations for DNS record modification, + as noted above. On the other hand, if disused address were not to be + assigned, host-based DNS reverse updates would have similar + considerations as SLAAC in Section 7.3. Server-based updates have + similar properties except that the janitorial process could be + integrated with DHCP address assignment. + + +7.5 DDNS with Dynamic Prefix Delegation + + + In cases where a prefix, instead of an address, is being used and + updated, one should consider what is the location of the server where + DDNS updates are made. That is, where the DNS server is located: + + + 1. At the same organization as the prefix delegator. + + + 2. At the site where the prefixes are delegated to. In this case, + the authority of the DNS reverse zone corresponding to the + delegated prefix is also delegated to the site. + + + 3. Elsewhere; this implies a relationship between the site and where + DNS server is located, and such a relationship should be rather + straightforward to secure as well. Like in the previous case, + the authority of the DNS reverse zone is also delegated. + + + In the first case, managing the reverse DNS (delegation) is simpler + as the DNS server and the prefix delegator are in the same + administrative domain (as there is no need to delegate anything at + all); alternatively, the prefix delegator might forgo DDNS reverse + capability altogether, and use e.g., wildcard records (as described + in Section 7.2). In the other cases, it can be slighly more + difficult, particularly as the site will have to configure the DNS + server to be authoritative for the delegated reverse zone, implying + automatic configuration of the DNS server -- as the prefix may be + dynamic. + + + Managing the DDNS reverse updates is typically simple in the second + case, as the updated server is located at the local site, and + arguably IP address-based authentication could be sufficient (or if + not, setting up security relationships would be simpler). As there + is an explicit (security) relationship between the parties in the + third case, setting up the security relationships to allow reverse + DDNS updates should be rather straightforward as well. In the first + case, however, setting up and managing such relationships might be a + lot more difficult. + + + + +Durand, et al. Expires January 16, 2005 [Page 21] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + +8. Miscellaneous DNS Considerations + + + This section describes miscellaneous considerations about DNS which + seem related to IPv6, for which no better place has been found in + this document. + + +8.1 NAT-PT with DNS-ALG + + + The DNS-ALG component of NAT-PT mangles A records to look like AAAA + records to the IPv6-only nodes. Numerous problems have been + identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues]. + This is a strong reason not to use NAT-PT in the first place. + + +8.2 Renumbering Procedures and Applications' Use of DNS + + + One of the most difficult problems of systematic IP address + renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that + an application which looks up a DNS name disregards information such + as TTL, and uses the result obtained from DNS as long as it happens + to be stored in the memory of the application. For applications + which run for a long time, this could be days, weeks or even months; + some applications may be clever enough to organize the data + structures and functions in such a manner that look-ups get refreshed + now and then. + + + While the issue appears to have a clear solution, "fix the + applications", practically this is not reasonable immediate advice; + the TTL information is not typically available in the APIs and + libraries (so, the advice becomes "fix the applications, APIs and + libraries"), and a lot more analysis is needed on how to practically + go about to achieve the ultimate goal of avoiding using the names + longer than expected. + + +9. Acknowledgements + + + Some recommendations (Section 4.3, Section 5.1) about IPv6 service + provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik + Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided + useful feedback and improvements. Scott Rose, Rob Austein, Masataka + Ohta, and Mark Andrews helped in clarifying the issues regarding + additional data and the use of TTL. Jefsey Morfin, Ralph Droms, + Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and + Rob Austein provided useful feedback during the WG last call. Thomas + Narten provided extensive feedback during the IESG evaluation. + + +10. Security Considerations + + + This document reviews the operational procedures for IPv6 DNS + + + + +Durand, et al. Expires January 16, 2005 [Page 22] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + operations and does not have security considerations in itself. + + + However, it is worth noting that in particular with Dynamic DNS + Updates, security models based on the source address validation are + very weak and cannot be recommended -- they could only be considered + in the environments where ingress filtering [RFC3704] has been + deployed. On the other hand, it should be noted that setting up an + authorization mechanism (e.g., a shared secret, or public-private + keys) between a node and the DNS server has to be done manually, and + may require quite a bit of time and expertise. + + + To re-emphasize which was already stated, the reverse+forward DNS + check provides very weak security at best, and the only + (questionable) security-related use for them may be in conjunction + with other mechanisms when authenticating a user. + + +11. References + + +11.1 Normative References + + + [I-D.ietf-dnsop-ipv6-dns-configuration] + Jeong, J., "IPv6 Host Configuration of DNS Server + Information Approaches", + draft-ietf-dnsop-ipv6-dns-configuration-01 (work in + progress), June 2004. + + + [I-D.ietf-dnsop-ipv6-transport-guidelines] + Durand, A. and J. Ihren, "DNS IPv6 transport operational + guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02 + (work in progress), March 2004. + + + [I-D.ietf-dnsop-misbehavior-against-aaaa] + Morishita, Y. and T. Jinmei, "Common Misbehavior against + DNS Queries for IPv6 Addresses", + draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in + progress), April 2004. + + + [I-D.ietf-ipv6-deprecate-site-local] + Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work + in progress), March 2004. + + + [I-D.ietf-v6ops-application-transition] + Shin, M., "Application Aspects of IPv6 Transition", + draft-ietf-v6ops-application-transition-03 (work in + progress), June 2004. + + + [I-D.ietf-v6ops-renumbering-procedure] + + + + +Durand, et al. Expires January 16, 2005 [Page 23] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + Baker, F., Lear, E. and R. Droms, "Procedures for + Renumbering an IPv6 Network without a Flag Day", + draft-ietf-v6ops-renumbering-procedure-01 (work in + progress), July 2004. + + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + + [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection + and Operation of Secondary DNS Servers", BCP 16, RFC 2182, + July 1997. + + + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC 3041, + January 2001. + + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + + + [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and + M. Carney, "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + + + [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) + Support for Internet Protocol version 6 (IPv6)", RFC 3364, + August 2002. + + + + + +Durand, et al. Expires January 16, 2005 [Page 24] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October + 2003. + + + [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol + (DHCP) Service for IPv6", RFC 3736, April 2004. + + +11.2 Informative References + + + [I-D.durand-v6ops-natpt-dns-alg-issues] + Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", + draft-durand-v6ops-natpt-dns-alg-issues-00 (work in + progress), February 2003. + + + [I-D.huitema-v6ops-teredo] + Huitema, C., "Teredo: Tunneling IPv6 over UDP through + NATs", draft-huitema-v6ops-teredo-02 (work in progress), + June 2004. + + + [I-D.huston-6to4-reverse-dns] + Huston, G., "6to4 Reverse DNS", + draft-huston-6to4-reverse-dns-02 (work in progress), April + 2004. + + + [I-D.ietf-dhc-ddns-resolution] + Stapp, M., "Resolution of DNS Name Conflicts Among DHCP + Clients", draft-ietf-dhc-ddns-resolution-06 (work in + progress), October 2003. + + + [I-D.ietf-dhc-fqdn-option] + Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", + draft-ietf-dhc-fqdn-option-06 (work in progress), October + 2003. + + + [I-D.ietf-dnsext-dhcid-rr] + Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for + encoding DHCP information (DHCID RR)", + draft-ietf-dnsext-dhcid-rr-07 (work in progress), October + 2003. + + + [I-D.ietf-dnsop-bad-dns-res] + + + + +Durand, et al. Expires January 16, 2005 [Page 25] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + Larson, M. and P. Barber, "Observed DNS Resolution + Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in + progress), June 2003. + + + [I-D.ietf-dnsop-dontpublish-unreachable] + Hazel, P., "IP Addresses that should never appear in the + public DNS", draft-ietf-dnsop-dontpublish-unreachable-03 + (work in progress), February 2002. + + + [I-D.ietf-dnsop-inaddr-required] + Senie, D., "Requiring DNS IN-ADDR Mapping", + draft-ietf-dnsop-inaddr-required-05 (work in progress), + April 2004. + + + [I-D.ietf-ipseckey-rr] + Richardson, M., "A method for storing IPsec keying + material in DNS", draft-ietf-ipseckey-rr-10 (work in + progress), April 2004. + + + [I-D.ietf-ipv6-unique-local-addr] + Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in + progress), June 2004. + + + [I-D.ietf-send-cga] + Aura, T., "Cryptographically Generated Addresses (CGA)", + draft-ietf-send-cga-06 (work in progress), April 2004. + + + [I-D.ietf-v6ops-3gpp-analysis] + Wiljakka, J., "Analysis on IPv6 Transition in 3GPP + Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in + progress), May 2004. + + + [I-D.ietf-v6ops-mech-v2] + Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms + for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 + (work in progress), June 2004. + + + [I-D.ietf-v6ops-onlinkassumption] + Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery + On-Link Assumption Considered Harmful", + draft-ietf-v6ops-onlinkassumption-02 (work in progress), + May 2004. + + + [I-D.ietf-v6ops-v6onbydefault] + Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack + IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-02 + (work in progress), May 2004. + + + + +Durand, et al. Expires January 16, 2005 [Page 26] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + [I-D.jeong-dnsop-ipv6-dns-discovery] + Jeong, J., "IPv6 DNS Discovery based on Router + Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-01 + (work in progress), February 2004. + + + [I-D.moore-6to4-dns] + Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work + in progress), October 2002. + + + [I-D.ohta-preconfigured-dns] + Ohta, M., "Preconfigured DNS Server Addresses", + draft-ohta-preconfigured-dns-01 (work in progress), + February 2004. + + + [I-D.savola-v6ops-6bone-mess] + Savola, P., "Moving from 6bone to IPv6 Internet", + draft-savola-v6ops-6bone-mess-01 (work in progress), + November 2002. + + + [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address + Translation - Protocol Translation (NAT-PT)", RFC 2766, + February 2000. + + + [RFC2826] Internet Architecture Board, "IAB Technical Comment on the + Unique DNS Root", RFC 2826, May 2000. + + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, March 2004. + + + +Authors' Addresses + + + Alain Durand + SUN Microsystems, Inc. + 17 Network circle UMPL17-202 + Menlo Park, CA 94025 + USA + + + EMail: Alain.Durand@sun.com + + + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm + Sweden + + + EMail: johani@autonomica.se + + + + +Durand, et al. Expires January 16, 2005 [Page 27] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + Pekka Savola + CSC/FUNET + Espoo + Finland + + + EMail: psavola@funet.fi + + +Appendix A. Site-local Addressing Considerations for DNS + + + As site-local addressing is being deprecated, the considerations for + site-local addressing are discussed briefly here. Unique local + addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed + as a replacement, but being work-in-progress, it is not considered + further. + + + The interactions with DNS come in two flavors: forward and reverse + DNS. + + + To actually use site-local addresses within a site, this implies the + deployment of a "split-faced" or a fragmented DNS name space, for the + zones internal to the site, and the outsiders' view to it. The + procedures to achieve this are not elaborated here. The implication + is that site-local addresses must not be published in the public DNS. + + + To faciliate reverse DNS (if desired) with site-local addresses, the + stub resolvers must look for DNS information from the local DNS + servers, not e.g. starting from the root servers, so that the + site-local information may be provided locally. Note that the + experience of private addresses in IPv4 has shown that the root + servers get loaded for requests for private address lookups in any + case. + + +Appendix B. Issues about Additional Data or TTL + + + [[ note to the RFC-editor: remove this section upon publication. ]] + + + This appendix tries to describe the apparent rought consensus about + additional data and TTL issues (sections 4.4 and 4.5), and present + questions when there appears to be no consensus. The point of + recording them here is to focus the discussio and get feedback. + + + Resolved: + + + a. If some critical additional data RRsets wouldn't fit, you set the + TC bit even if some RRsets did fit. + + + b. If some courtesy additional data RRsets wouldn't fit, you never + set the TC bit, but rather remove (at least some of) the courtesy + + + + +Durand, et al. Expires January 16, 2005 [Page 28] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + + RRsets. + + + c. DNS servers should implement sanity checks on the resulting glue, + e.g., to disable circular dependencies. Then the responding + servers can use at-or-below-a-zone-cut criterion to determine + whether the additional data is critical or not. + + + Open issues (at least): + + + 1. if some critical additional data RRsets would fit, but some + wouldn't, and TC has to be set (see above), should one rather + remove the additional data that did fit, keep it, or leave + unspecified? + + + 2. if some courtesy additional data RRsets would fit, but some + wouldn't, and some will have to be removed from the response (no + TC is set, see above), what to do -- remove all courtesy RRsets, + keep all that fit, or leave unspecified? + + + 3. is it acceptable to use the transport used in the DNS query as a + hint which records to keep if not removing all the RRsets, if: a) + having to decide which critical additional data to keep, or b) + having to decide which courtesy additional data to keep? + + + 4. (this issue was discussed in section 4.5) if one RRset has TTL of + 100 seconds, and another the TTL of 300 seconds, what should the + caching server do after 100 seconds? Keep returning just one + RRset when returning additional data, or discard the other RRset + from the cache? + + + 5. how do we move forward from here? If we manage to get to some + form of consensus, how do we record it: a) just in + draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational + category only!), b) a separate BCP or similar by DNSEXT WG(?), + clarifying and giving recommendations, c) something else, what? + + + + + + + + + + + + + + + + + +Durand, et al. Expires January 16, 2005 [Page 29] +Internet-Draft Considerations and Issues with IPv6 DNS July 2004 + + + +Intellectual Property Statement + + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + +Disclaimer of Validity + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Copyright Statement + + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + +Acknowledgment + + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + +Durand, et al. Expires January 16, 2005 [Page 30] \ No newline at end of file