diff options
| author | dougb <dougb@FreeBSD.org> | 2007-06-02 23:29:48 +0000 |
|---|---|---|
| committer | dougb <dougb@FreeBSD.org> | 2007-06-02 23:29:48 +0000 |
| commit | 4aa2d28999e7ee0d0357c0dbff0f8c4d4fc5fc8a (patch) | |
| tree | f44111a5184843be0e67618ed57e44b5620e27a2 /contrib | |
| parent | 5b21df8b3033100585043560a105fc40260fad80 (diff) | |
| download | FreeBSD-src-4aa2d28999e7ee0d0357c0dbff0f8c4d4fc5fc8a.zip FreeBSD-src-4aa2d28999e7ee0d0357c0dbff0f8c4d4fc5fc8a.tar.gz | |
This commit was generated by cvs2svn to compensate for changes in r170225,
which included commits to RCS files with non-trunk default branches.
Diffstat (limited to 'contrib')
12 files changed, 0 insertions, 10066 deletions
diff --git a/contrib/bind9/bin/named/aclconf.c b/contrib/bind9/bin/named/aclconf.c deleted file mode 100644 index 102a891..0000000 --- a/contrib/bind9/bin/named/aclconf.c +++ /dev/null @@ -1,252 +0,0 @@ -/* - * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC") - * Copyright (C) 1999-2002 Internet Software Consortium. - * - * Permission to use, copy, modify, and distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH - * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY - * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, - * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM - * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE - * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - * PERFORMANCE OF THIS SOFTWARE. - */ - -/* $Id: aclconf.c,v 1.27.12.7 2006/03/02 00:37:20 marka Exp $ */ - -#include <config.h> - -#include <isc/mem.h> -#include <isc/string.h> /* Required for HP/UX (and others?) */ -#include <isc/util.h> - -#include <isccfg/namedconf.h> - -#include <dns/acl.h> -#include <dns/fixedname.h> -#include <dns/log.h> - -#include <named/aclconf.h> - -#define LOOP_MAGIC ISC_MAGIC('L','O','O','P') - -void -ns_aclconfctx_init(ns_aclconfctx_t *ctx) { - ISC_LIST_INIT(ctx->named_acl_cache); -} - -void -ns_aclconfctx_destroy(ns_aclconfctx_t *ctx) { - dns_acl_t *dacl, *next; - for (dacl = ISC_LIST_HEAD(ctx->named_acl_cache); - dacl != NULL; - dacl = next) - { - next = ISC_LIST_NEXT(dacl, nextincache); - dns_acl_detach(&dacl); - } -} - -/* - * Find the definition of the named acl whose name is "name". - */ -static isc_result_t -get_acl_def(const cfg_obj_t *cctx, const char *name, const cfg_obj_t **ret) { - isc_result_t result; - const cfg_obj_t *acls = NULL; - const cfg_listelt_t *elt; - - result = cfg_map_get(cctx, "acl", &acls); - if (result != ISC_R_SUCCESS) - return (result); - for (elt = cfg_list_first(acls); - elt != NULL; - elt = cfg_list_next(elt)) { - const cfg_obj_t *acl = cfg_listelt_value(elt); - const char *aclname = cfg_obj_asstring(cfg_tuple_get(acl, "name")); - if (strcasecmp(aclname, name) == 0) { - *ret = cfg_tuple_get(acl, "value"); - return (ISC_R_SUCCESS); - } - } - return (ISC_R_NOTFOUND); -} - -static isc_result_t -convert_named_acl(const cfg_obj_t *nameobj, const cfg_obj_t *cctx, - ns_aclconfctx_t *ctx, isc_mem_t *mctx, - dns_acl_t **target) -{ - isc_result_t result; - const cfg_obj_t *cacl = NULL; - dns_acl_t *dacl; - dns_acl_t loop; - const char *aclname = cfg_obj_asstring(nameobj); - - /* Look for an already-converted version. */ - for (dacl = ISC_LIST_HEAD(ctx->named_acl_cache); - dacl != NULL; - dacl = ISC_LIST_NEXT(dacl, nextincache)) - { - if (strcasecmp(aclname, dacl->name) == 0) { - if (ISC_MAGIC_VALID(dacl, LOOP_MAGIC)) { - cfg_obj_log(nameobj, dns_lctx, ISC_LOG_ERROR, - "acl loop detected: %s", aclname); - return (ISC_R_FAILURE); - } - dns_acl_attach(dacl, target); - return (ISC_R_SUCCESS); - } - } - /* Not yet converted. Convert now. */ - result = get_acl_def(cctx, aclname, &cacl); - if (result != ISC_R_SUCCESS) { - cfg_obj_log(nameobj, dns_lctx, ISC_LOG_WARNING, - "undefined ACL '%s'", aclname); - return (result); - } - /* - * Add a loop detection element. - */ - memset(&loop, 0, sizeof(loop)); - ISC_LINK_INIT(&loop, nextincache); - DE_CONST(aclname, loop.name); - loop.magic = LOOP_MAGIC; - ISC_LIST_APPEND(ctx->named_acl_cache, &loop, nextincache); - result = ns_acl_fromconfig(cacl, cctx, ctx, mctx, &dacl); - ISC_LIST_UNLINK(ctx->named_acl_cache, &loop, nextincache); - loop.magic = 0; - loop.name = NULL; - if (result != ISC_R_SUCCESS) - return (result); - dacl->name = isc_mem_strdup(dacl->mctx, aclname); - if (dacl->name == NULL) - return (ISC_R_NOMEMORY); - ISC_LIST_APPEND(ctx->named_acl_cache, dacl, nextincache); - dns_acl_attach(dacl, target); - return (ISC_R_SUCCESS); -} - -static isc_result_t -convert_keyname(const cfg_obj_t *keyobj, isc_mem_t *mctx, dns_name_t *dnsname) { - isc_result_t result; - isc_buffer_t buf; - dns_fixedname_t fixname; - unsigned int keylen; - const char *txtname = cfg_obj_asstring(keyobj); - - keylen = strlen(txtname); - isc_buffer_init(&buf, txtname, keylen); - isc_buffer_add(&buf, keylen); - dns_fixedname_init(&fixname); - result = dns_name_fromtext(dns_fixedname_name(&fixname), &buf, - dns_rootname, ISC_FALSE, NULL); - if (result != ISC_R_SUCCESS) { - cfg_obj_log(keyobj, dns_lctx, ISC_LOG_WARNING, - "key name '%s' is not a valid domain name", - txtname); - return (result); - } - return (dns_name_dup(dns_fixedname_name(&fixname), mctx, dnsname)); -} - -isc_result_t -ns_acl_fromconfig(const cfg_obj_t *caml, - const cfg_obj_t *cctx, - ns_aclconfctx_t *ctx, - isc_mem_t *mctx, - dns_acl_t **target) -{ - isc_result_t result; - unsigned int count; - dns_acl_t *dacl = NULL; - dns_aclelement_t *de; - const cfg_listelt_t *elt; - - REQUIRE(target != NULL && *target == NULL); - - count = 0; - for (elt = cfg_list_first(caml); - elt != NULL; - elt = cfg_list_next(elt)) - count++; - - result = dns_acl_create(mctx, count, &dacl); - if (result != ISC_R_SUCCESS) - return (result); - - de = dacl->elements; - for (elt = cfg_list_first(caml); - elt != NULL; - elt = cfg_list_next(elt)) - { - const cfg_obj_t *ce = cfg_listelt_value(elt); - if (cfg_obj_istuple(ce)) { - /* This must be a negated element. */ - ce = cfg_tuple_get(ce, "value"); - de->negative = ISC_TRUE; - } else { - de->negative = ISC_FALSE; - } - - if (cfg_obj_isnetprefix(ce)) { - /* Network prefix */ - de->type = dns_aclelementtype_ipprefix; - - cfg_obj_asnetprefix(ce, - &de->u.ip_prefix.address, - &de->u.ip_prefix.prefixlen); - } else if (cfg_obj_istype(ce, &cfg_type_keyref)) { - /* Key name */ - de->type = dns_aclelementtype_keyname; - dns_name_init(&de->u.keyname, NULL); - result = convert_keyname(ce, mctx, &de->u.keyname); - if (result != ISC_R_SUCCESS) - goto cleanup; - } else if (cfg_obj_islist(ce)) { - /* Nested ACL */ - de->type = dns_aclelementtype_nestedacl; - result = ns_acl_fromconfig(ce, cctx, ctx, mctx, - &de->u.nestedacl); - if (result != ISC_R_SUCCESS) - goto cleanup; - } else if (cfg_obj_isstring(ce)) { - /* ACL name */ - const char *name = cfg_obj_asstring(ce); - if (strcasecmp(name, "localhost") == 0) { - de->type = dns_aclelementtype_localhost; - } else if (strcasecmp(name, "localnets") == 0) { - de->type = dns_aclelementtype_localnets; - } else if (strcasecmp(name, "any") == 0) { - de->type = dns_aclelementtype_any; - } else if (strcasecmp(name, "none") == 0) { - de->type = dns_aclelementtype_any; - de->negative = ISC_TF(! de->negative); - } else { - de->type = dns_aclelementtype_nestedacl; - result = convert_named_acl(ce, cctx, ctx, mctx, - &de->u.nestedacl); - if (result != ISC_R_SUCCESS) - goto cleanup; - } - } else { - cfg_obj_log(ce, dns_lctx, ISC_LOG_WARNING, - "address match list contains " - "unsupported element type"); - result = ISC_R_FAILURE; - goto cleanup; - } - de++; - dacl->length++; - } - - *target = dacl; - return (ISC_R_SUCCESS); - - cleanup: - dns_acl_detach(&dacl); - return (result); -} diff --git a/contrib/bind9/bin/named/include/named/aclconf.h b/contrib/bind9/bin/named/include/named/aclconf.h deleted file mode 100644 index a5b333a..0000000 --- a/contrib/bind9/bin/named/include/named/aclconf.h +++ /dev/null @@ -1,72 +0,0 @@ -/* - * Copyright (C) 2004, 2006 Internet Systems Consortium, Inc. ("ISC") - * Copyright (C) 1999-2001 Internet Software Consortium. - * - * Permission to use, copy, modify, and distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH - * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY - * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, - * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM - * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE - * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - * PERFORMANCE OF THIS SOFTWARE. - */ - -/* $Id: aclconf.h,v 1.12.208.3 2006/03/02 00:37:20 marka Exp $ */ - -#ifndef NS_ACLCONF_H -#define NS_ACLCONF_H 1 - -#include <isc/lang.h> - -#include <isccfg/cfg.h> - -#include <dns/types.h> - -typedef struct ns_aclconfctx { - ISC_LIST(dns_acl_t) named_acl_cache; -} ns_aclconfctx_t; - -/*** - *** Functions - ***/ - -ISC_LANG_BEGINDECLS - -void -ns_aclconfctx_init(ns_aclconfctx_t *ctx); -/* - * Initialize an ACL configuration context. - */ - -void -ns_aclconfctx_destroy(ns_aclconfctx_t *ctx); -/* - * Destroy an ACL configuration context. - */ - -isc_result_t -ns_acl_fromconfig(const cfg_obj_t *caml, - const cfg_obj_t *cctx, - ns_aclconfctx_t *ctx, - isc_mem_t *mctx, - dns_acl_t **target); -/* - * Construct a new dns_acl_t from configuration data in 'caml' and - * 'cctx'. Memory is allocated through 'mctx'. - * - * Any named ACLs referred to within 'caml' will be be converted - * inte nested dns_acl_t objects. Multiple references to the same - * named ACLs will be converted into shared references to a single - * nested dns_acl_t object when the referring objects were created - * passing the same ACL configuration context 'ctx'. - * - * On success, attach '*target' to the new dns_acl_t object. - */ - -ISC_LANG_ENDDECLS - -#endif /* NS_ACLCONF_H */ diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt deleted file mode 100644 index 2cd9724..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt +++ /dev/null @@ -1,562 +0,0 @@ - - - - -DNSEXT M. Stapp -Internet-Draft Cisco Systems, Inc. -Expires: August 13, 2005 T. Lemon - A. Gustafsson - Nominum, Inc. - February 9, 2005 - - - A DNS RR for Encoding DHCP Information (DHCID RR) - <draft-ietf-dnsext-dhcid-rr-09.txt> - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 13, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - It is possible for multiple DHCP clients to attempt to update the - same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or - the clients themselves perform the DNS updates, conflicts can arise. - To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] - - - -Stapp, et al. Expires August 13, 2005 [Page 1] - -Internet-Draft The DHCID RR February 2005 - - - proposes storing client identifiers in the DNS to unambiguously - associate domain names with the DHCP clients to which they refer. - This memo defines a distinct RR type for this purpose for use by DHCP - clients and servers, the "DHCID" RR. - -Table of Contents - - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4 - 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4 - 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4 - 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4 - 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6 - 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6 - 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 - 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 - Intellectual Property and Copyright Statements . . . . . . . . 10 - - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et al. Expires August 13, 2005 [Page 2] - -Internet-Draft The DHCID RR February 2005 - - -1. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [2]. - -2. Introduction - - A set of procedures to allow DHCP [7] clients and servers to - automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed - in "Resolution of DNS Name Conflicts" [1]. - - Conflicts can arise if multiple DHCP clients wish to use the same DNS - name. To resolve such conflicts, "Resolution of DNS Name Conflicts" - [1] proposes storing client identifiers in the DNS to unambiguously - associate domain names with the DHCP clients using them. In the - interest of clarity, it is preferable for this DHCP information to - use a distinct RR type. This memo defines a distinct RR for this - purpose for use by DHCP clients or servers, the "DHCID" RR. - - In order to avoid exposing potentially sensitive identifying - information, the data stored is the result of a one-way MD5 [5] hash - computation. The hash includes information from the DHCP client's - REQUEST message as well as the domain name itself, so that the data - stored in the DHCID RR will be dependent on both the client - identification used in the DHCP protocol interaction and the domain - name. This means that the DHCID RDATA will vary if a single client - is associated over time with more than one name. This makes it - difficult to 'track' a client as it is associated with various domain - names. - - The MD5 hash algorithm has been shown to be weaker than the SHA-1 - algorithm; it could therefore be argued that SHA-1 is a better - choice. However, SHA-1 is significantly slower than MD5. A - successful attack of MD5's weakness does not reveal the original data - that was used to generate the signature, but rather provides a new - set of input data that will produce the same signature. Because we - are using the MD5 hash to conceal the original data, the fact that an - attacker could produce a different plaintext resulting in the same - MD5 output is not significant concern. - -3. The DHCID RR - - The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The - DHCID RR is only defined in the IN class. DHCID RRs cause no - additional section processing. The DHCID RR is not a singleton type. - - - - - -Stapp, et al. Expires August 13, 2005 [Page 3] - -Internet-Draft The DHCID RR February 2005 - - -3.1 DHCID RDATA format - - The RDATA section of a DHCID RR in transmission contains RDLENGTH - bytes of binary data. The format of this data and its interpretation - by DHCP servers and clients are described below. - - DNS software should consider the RDATA section to be opaque. DHCP - clients or servers use the DHCID RR to associate a DHCP client's - identity with a DNS name, so that multiple DHCP clients and servers - may deterministically perform dynamic DNS updates to the same zone. - From the updater's perspective, the DHCID resource record RDATA - consists of a 16-bit identifier type, in network byte order, followed - by one or more bytes representing the actual identifier: - - < 16 bits > DHCP identifier used - < n bytes > MD5 digest - - -3.2 DHCID Presentation Format - - In DNS master files, the RDATA is represented as a single block in - base 64 encoding identical to that used for representing binary data - in RFC 2535 [8]. The data may be divided up into any number of white - space separated substrings, down to single base 64 digits, which are - concatenated to form the complete RDATA. These substrings can span - lines using the standard parentheses. - -3.3 The DHCID RR Type Codes - - The DHCID RR Type Code specifies what data from the DHCP client's - request was used as input into the hash function. The type codes are - defined in a registry maintained by IANA, as specified in Section 7. - The initial list of assigned values for the type code is: - - 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7]. - 0x0001 = The data portion from a DHCPv4 client's Client Identifier - option [9]. - 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6 - client's Client Identifier option [10] or the DUID field from a - DHCPv4 client's Client Identifier option [12]). - - 0x0003 - 0xfffe = Available to be assigned by IANA. - - 0xffff = RESERVED - -3.4 Computation of the RDATA - - The DHCID RDATA is formed by concatenating the two type bytes with - - - -Stapp, et al. Expires August 13, 2005 [Page 4] - -Internet-Draft The DHCID RR February 2005 - - - some variable-length identifying data. - - < type > < data > - - The RDATA for all type codes other than 0xffff, which is reserved for - future expansion, is formed by concatenating the two type bytes and a - 16-byte MD5 hash value. The input to the hash function is defined to - be: - - data = MD5(< identifier > < FQDN >) - - The FQDN is represented in the buffer in unambiguous canonical form - as described in RFC 2535 [8], section 8.1. The type code and the - identifier are related as specified in Section 3.3: the type code - describes the source of the identifier. - - When the updater is using the client's link-layer address as the - identifier, the first two bytes of the DHCID RDATA MUST be zero. To - generate the rest of the resource record, the updater computes a - one-way hash using the MD5 algorithm across a buffer containing the - client's network hardware type, link-layer address, and the FQDN - data. Specifically, the first byte of the buffer contains the - network hardware type as it appeared in the DHCP 'htype' field of the - client's DHCPREQUEST message. All of the significant bytes of the - chaddr field in the client's DHCPREQUEST message follow, in the same - order in which the bytes appear in the DHCPREQUEST message. The - number of significant bytes in the 'chaddr' field is specified in the - 'hlen' field of the DHCPREQUEST message. The FQDN data, as specified - above, follows. - - When the updater is using the DHCPv4 Client Identifier option sent by - the client in its DHCPREQUEST message, the first two bytes of the - DHCID RR MUST be 0x0001, in network byte order. The rest of the - DHCID RR MUST contain the results of computing an MD5 hash across the - payload of the option, followed by the FQDN. The payload of the - option consists of the bytes of the option following the option code - and length. - - When the updater is using the DHCPv6 DUID sent by the client in its - REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002, - in network byte order. The rest of the DHCID RR MUST contain the - results of computing an MD5 hash across the payload of the option, - followed by the FQDN. The payload of the option consists of the - bytes of the option following the option code and length. - -3.5 Examples - - - - - -Stapp, et al. Expires August 13, 2005 [Page 5] - -Internet-Draft The DHCID RR February 2005 - - -3.5.1 Example 1 - - A DHCP server allocating the IPv4 address 10.0.0.1 to a client with - Ethernet MAC address 01:02:03:04:05:06 using domain name - "client.example.com" uses the client's link-layer address to identify - the client. The DHCID RDATA is composed by setting the two type - bytes to zero, and performing an MD5 hash computation across a buffer - containing the Ethernet MAC type byte, 0x01, the six bytes of MAC - address, and the domain name (represented as specified in - Section 3.4). - - client.example.com. A 10.0.0.1 - client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU - - -3.5.2 Example 2 - - A DHCP server allocates the IPv4 address 10.0.12.99 to a client which - included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c - in its DHCP request. The server updates the name "chi.example.com" - on the client's behalf, and uses the DHCP client identifier option - data as input in forming a DHCID RR. The DHCID RDATA is formed by - setting the two type bytes to the value 0x0001, and performing an MD5 - hash computation across a buffer containing the seven bytes from the - client-id option and the FQDN (represented as specified in - Section 3.4). - - chi.example.com. A 10.0.12.99 - chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012 - - -4. Use of the DHCID RR - - This RR MUST NOT be used for any purpose other than that detailed in - "Resolution of DNS Name Conflicts" [1]. Although this RR contains - data that is opaque to DNS servers, the data must be consistent - across all entities that update and interpret this record. - Therefore, new data formats may only be defined through actions of - the DHC Working Group, as a result of revising [1]. - -5. Updater Behavior - - The data in the DHCID RR allows updaters to determine whether more - than one DHCP client desires to use a particular FQDN. This allows - site administrators to establish policy about DNS updates. The DHCID - RR does not establish any policy itself. - - Updaters use data from a DHCP client's request and the domain name - - - -Stapp, et al. Expires August 13, 2005 [Page 6] - -Internet-Draft The DHCID RR February 2005 - - - that the client desires to use to compute a client identity hash, and - then compare that hash to the data in any DHCID RRs on the name that - they wish to associate with the client's IP address. If an updater - discovers DHCID RRs whose RDATA does not match the client identity - that they have computed, the updater SHOULD conclude that a different - client is currently associated with the name in question. The - updater SHOULD then proceed according to the site's administrative - policy. That policy might dictate that a different name be selected, - or it might permit the updater to continue. - -6. Security Considerations - - The DHCID record as such does not introduce any new security problems - into the DNS. In order to avoid exposing private information about - DHCP clients to public scrutiny, a one-way hash is used to obscure - all client information. In order to make it difficult to 'track' a - client by examining the names associated with a particular hash - value, the FQDN is included in the hash computation. Thus, the RDATA - is dependent on both the DHCP client identification data and on each - FQDN associated with the client. - - Administrators should be wary of permitting unsecured DNS updates to - zones which are exposed to the global Internet. Both DHCP clients - and servers SHOULD use some form of update authentication (e.g., TSIG - [11]) when performing DNS updates. - -7. IANA Considerations - - IANA is requested to allocate an RR type number for the DHCID record - type. - - This specification defines a new number-space for the 16-bit type - codes associated with the DHCID RR. IANA is requested to establish a - registry of the values for this number-space. - - Three initial values are assigned in Section 3.3, and the value - 0xFFFF is reserved for future use. New DHCID RR type codes are - tentatively assigned after the specification for the associated type - code, published as an Internet Draft, has received expert review by a - designated expert. The final assignment of DHCID RR type codes is - through Standards Action, as defined in RFC 2434 [6]. - -8. Acknowledgements - - Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and - Ralph Droms for their review and suggestions. - - - - - -Stapp, et al. Expires August 13, 2005 [Page 7] - -Internet-Draft The DHCID RR February 2005 - - -9. References - -9.1 Normative References - - [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among - DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [4] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April - 1992. - - [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - -9.2 Informative References - - [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - - [8] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, March 1997. - - [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. - Carney, "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers - for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004. - - - - - - - - -Stapp, et al. Expires August 13, 2005 [Page 8] - -Internet-Draft The DHCID RR February 2005 - - -Authors' Addresses - - Mark Stapp - Cisco Systems, Inc. - 1414 Massachusetts Ave. - Boxborough, MA 01719 - USA - - Phone: 978.936.1535 - Email: mjs@cisco.com - - - Ted Lemon - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - USA - - Email: mellon@nominum.com - - - Andreas Gustafsson - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - USA - - Email: gson@nominum.com - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et al. Expires August 13, 2005 [Page 9] - -Internet-Draft The DHCID RR February 2005 - - -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 (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Stapp, et al. Expires August 13, 2005 [Page 10] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt deleted file mode 100644 index f7abddc..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt +++ /dev/null @@ -1,560 +0,0 @@ - - - -Network Working Group S. Weiler -Internet-Draft SPARTA, Inc -Updates: 4034, 4035 (if approved) J. Ihren -Expires: November 13, 2005 Autonomica AB - May 12, 2005 - - - Minimally Covering NSEC Records and DNSSEC On-line Signing - draft-ietf-dnsext-dnssec-online-signing-00 - -Status of this Memo - - 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 becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - 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 13, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document describes how to construct DNSSEC NSEC resource records - that cover a smaller range of names than called for by RFC4034. By - generating and signing these records on demand, authoritative name - servers can effectively stop the disclosure of zone contents - otherwise made possible by walking the chain of NSEC records in a - signed zone. - - - - -Weiler & Ihren Expires November 13, 2005 [Page 1] - -Internet-Draft NSEC Epsilon May 2005 - - -Changes from weiler-01 to ietf-00 - - Inserted RFC numbers for 4033, 4034, and 4035. - - Specified contents of bitmap field in synthesized NSEC RR's, pointing - out that this relaxes a constraint in 4035. Added 4035 to the - Updates header. - -Changes from weiler-00 to weiler-01 - - Clarified that this updates RFC4034 by relaxing requirements on the - next name field. - - Added examples covering wildcard names. - - In the 'better functions' section, reiterated that perfect functions - aren't needed. - - Added a reference to RFC 2119. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires November 13, 2005 [Page 2] - -Internet-Draft NSEC Epsilon May 2005 - - -Table of Contents - - 1. Introduction and Terminology . . . . . . . . . . . . . . . . 4 - 2. Minimally Covering NSEC Records . . . . . . . . . . . . . . 4 - 3. Better Increment & Decrement Functions . . . . . . . . . . . 6 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 - 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 - 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 - A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 - Intellectual Property and Copyright Statements . . . . . . . 10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires November 13, 2005 [Page 3] - -Internet-Draft NSEC Epsilon May 2005 - - -1. Introduction and Terminology - - With DNSSEC [1], an NSEC record lists the next instantiated name in - its zone, proving that no names exist in the "span" between the - NSEC's owner name and the name in the "next name" field. In this - document, an NSEC record is said to "cover" the names between its - owner name and next name. - - Through repeated queries that return NSEC records, it is possible to - retrieve all of the names in the zone, a process commonly called - "walking" the zone. Some zone owners have policies forbidding zone - transfers by arbitrary clients; this side-effect of the NSEC - architecture subverts those policies. - - This document presents a way to prevent zone walking by constructing - NSEC records that cover fewer names. These records can make zone - walking take approximately as many queries as simply asking for all - possible names in a zone, making zone walking impractical. Some of - these records must be created and signed on demand, which requires - on-line private keys. Anyone contemplating use of this technique is - strongly encouraged to review the discussion of the risks of on-line - signing in Section 5. - - The technique presented here may be useful to a zone owner that wants - to use DNSSEC, is concerned about exposure of its zone contents via - zone walking, and is willing to bear the costs of on-line signing. - - 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 [4]. - -2. Minimally Covering NSEC Records - - This mechanism involves changes to NSEC records for instantiated - names, which can still be generated and signed in advance, as well as - the on-demand generation and signing of new NSEC records whenever a - name must be proven not to exist. - - In the 'next name' field of instantiated names' NSEC records, rather - than list the next instantiated name in the zone, list any name that - falls lexically after the NSEC's owner name and before the next - instantiated name in the zone, according to the ordering function in - RFC4034 [2] section 6.2. This relaxes the requirement in section - 4.1.1 of RFC4034 that the 'next name' field contains the next owner - name in the zone. This change is expected to be fully compatible - with all existing DNSSEC validators. These NSEC records are returned - whenever proving something specifically about the owner name (e.g. - that no resource records of a given type appear at that name). - - - -Weiler & Ihren Expires November 13, 2005 [Page 4] - -Internet-Draft NSEC Epsilon May 2005 - - - Whenever an NSEC record is needed to prove the non-existence of a - name, a new NSEC record is dynamically produced and signed. The new - NSEC record has an owner name lexically before the QNAME but - lexically following any existing name and a 'next name' lexically - following the QNAME but before any existing name. - - The generated NSEC record's type bitmap SHOULD have the RRSIG and - NSEC bits set and SHOULD NOT have any other bits set. This relaxes - the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at - names that did not exist before the zone wsa signed. - - The functions to generate the lexically following and proceeding - names need not be perfect nor consistent, but the generated NSEC - records must not cover any existing names. Furthermore, this - technique works best when the generated NSEC records cover as few - names as possible. - - An NSEC record denying the existence of a wildcard may be generated - in the same way. Since the NSEC record covering a non-existent - wildcard is likely to be used in response to many queries, - authoritative name servers using the techniques described here may - want to pregenerate or cache that record and its corresponding RRSIG. - - For example, a query for an A record at the non-instantiated name - example.com might produce the following two NSEC records, the first - denying the existence of the name example.com and the second denying - the existence of a wildcard: - - exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) - - ).com 3600 IN NSEC +.com ( RRSIG NSEC ) - - Before answering a query with these records, an authoritative server - must test for the existence of names between these endpoints. If the - generated NSEC would cover existing names (e.g. exampldd.com or - *bizarre.example.com), a better increment or decrement function may - be used or the covered name closest to the QNAME could be used as the - NSEC owner name or next name, as appropriate. If an existing name is - used as the NSEC owner name, that name's real NSEC record MUST be - returned. Using the same example, assuming an exampldd.com - delegation exists, this record might be returned from the parent: - - exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) - - Like every authoritative record in the zone, each generated NSEC - record MUST have corresponding RRSIGs generated using each algorithm - (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as - described in RFC4035 [3] section 2.2. To minimize the number of - - - -Weiler & Ihren Expires November 13, 2005 [Page 5] - -Internet-Draft NSEC Epsilon May 2005 - - - signatures that must be generated, a zone may wish to limit the - number of algorithms in its DNSKEY RRset. - -3. Better Increment & Decrement Functions - - Section 6.2 of RFC4034 defines a strict ordering of DNS names. - Working backwards from that definition, it should be possible to - define increment and decrement functions that generate the - immediately following and preceding names, respectively. This - document does not define such functions. Instead, this section - presents functions that come reasonably close to the perfect ones. - As described above, an authoritative server should still ensure than - no generated NSEC covers any existing name. - - To increment a name, add a leading label with a single null (zero- - value) octet. - - To decrement a name, decrement the last character of the leftmost - label, then fill that label to a length of 63 octets with octets of - value 255. To decrement a null (zero-value) octet, remove the octet - -- if an empty label is left, remove the label. Defining this - function numerically: fill the left-most label to its maximum length - with zeros (numeric, not ASCII zeros) and subtract one. - - In response to a query for the non-existent name foo.example.com, - these functions produce NSEC records of: - - fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) - - )\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG ) - - The first of these NSEC RRs proves that no exact match for - foo.example.com exists, and the second proves that there is no - wildcard in example.com. - - Both of these functions are imperfect: they don't take into account - constraints on number of labels in a name nor total length of a name. - As noted in the previous section, though, this technique does not - depend on the use of perfect increment or decrement functions: it is - sufficient to test whether any instantiated names fall into the span - - - -Weiler & Ihren Expires November 13, 2005 [Page 6] - -Internet-Draft NSEC Epsilon May 2005 - - - covered by the generated NSEC and, if so, substitute those - instantiated owner names for the NSEC owner name or next name, as - appropriate. - -4. IANA Considerations - - Per RFC4041, IANA should think carefully about the protection of - their immortal souls. - -5. Security Considerations - - This approach requires on-demand generation of RRSIG records. This - creates several new vulnerabilities. - - First, on-demand signing requires that a zone's authoritative servers - have access to its private keys. Storing private keys on well-known - internet-accessible servers may make them more vulnerable to - unintended disclosure. - - Second, since generation of public key signatures tends to be - computationally demanding, the requirement for on-demand signing - makes authoritative servers vulnerable to a denial of service attack. - - Lastly, if the increment and decrement functions are predictable, on- - demand signing may enable a chosen-plaintext attack on a zone's - private keys. Zones using this approach should attempt to use - cryptographic algorithms that are resistant to chosen-plaintext - attacks. It's worth noting that while DNSSEC has a "mandatory to - implement" algorithm, that is a requirement on resolvers and - validators -- there is no requirement that a zone be signed with any - given algorithm. - - The success of using minimally covering NSEC record to prevent zone - walking depends greatly on the quality of the increment and decrement - functions chosen. An increment function that chooses a name - obviously derived from the next instantiated name may be easily - reverse engineered, destroying the value of this technique. An - increment function that always returns a name close to the next - instantiated name is likewise a poor choice. Good choices of - increment and decrement functions are the ones that produce the - immediately following and preceding names, respectively, though zone - administrators may wish to use less perfect functions that return - more human-friendly names than the functions described in Section 3 - above. - - Another obvious but misguided concern is the danger from synthesized - NSEC records being replayed. It's possible for an attacker to replay - an old but still validly signed NSEC record after a new name has been - - - -Weiler & Ihren Expires November 13, 2005 [Page 7] - -Internet-Draft NSEC Epsilon May 2005 - - - added in the span covered by that NSEC, incorrectly proving that - there is no record at that name. This danger exists with DNSSEC as - defined in [-bis]. The techniques described here actually decrease - the danger, since the span covered by any NSEC record is smaller than - before. Choosing better increment and decrement functions will - further reduce this danger. - -6. Normative References - - [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - - [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - -Authors' Addresses - - Samuel Weiler - SPARTA, Inc - 7075 Samuel Morse Drive - Columbia, Maryland 21046 - US - - Email: weiler@tislabs.com - - - Johan Ihren - Autonomica AB - Bellmansgatan 30 - Stockholm SE-118 47 - Sweden - - Email: johani@autonomica.se - -Appendix A. Acknowledgments - - Many individuals contributed to this design. They include, in - addition to the authors of this document, Olaf Kolkman, Ed Lewis, - - - -Weiler & Ihren Expires November 13, 2005 [Page 8] - -Internet-Draft NSEC Epsilon May 2005 - - - Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, - Jakob Schlyter, Bill Manning, and Joao Damas. - - The key innovation of this document, namely that perfect increment - and decrement functions are not necessary, arose during a discussion - among the above-listed people at the RIPE49 meeting in September - 2004. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires November 13, 2005 [Page 9] - -Internet-Draft NSEC Epsilon May 2005 - - -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 (2005). 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. - - - - -Weiler & Ihren Expires November 13, 2005 [Page 10] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt deleted file mode 100644 index 1c4c3f6..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt +++ /dev/null @@ -1,754 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -Updates RFC 1034, 1035 Motorola Laboratories -Expires January 2006 July 2005 - - - - Domain Name System (DNS) Case Insensitivity Clarification - ------ ---- ------ ----- ---- ------------- ------------- - <draft-ietf-dnsext-insensitive-06.txt> - - Donald E. Eastlake 3rd - - - -Status of This Document - - 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 becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Distribution of this document is unlimited. Comments should be sent - to the DNSEXT working group at namedroppers@ops.ietf.org. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than a "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - - -Copyright Notice - - Copyright (C) The Internet Society (2005). All Rights Reserved. - - - -Abstract - - Domain Name System (DNS) names are "case insensitive". This document - explains exactly what that means and provides a clear specification - of the rules. This clarification updates RFCs 1034 and 1035. - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Acknowledgements - - The contributions to this document of Rob Austein, Olafur - Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, - Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman - are gratefully acknowledged. - - - -Table of Contents - - Status of This Document....................................1 - Copyright Notice...........................................1 - Abstract...................................................1 - - Acknowledgements...........................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. Case Insensitivity of DNS Labels........................3 - 2.1 Escaping Unusual DNS Label Octets......................3 - 2.2 Example Labels with Escapes............................4 - 3. Name Lookup, Label Types, and CLASS.....................4 - 3.1 Original DNS Label Types...............................5 - 3.2 Extended Label Type Case Insensitivity Considerations..5 - 3.3 CLASS Case Insensitivity Considerations................5 - 4. Case on Input and Output................................6 - 4.1 DNS Output Case Preservation...........................6 - 4.2 DNS Input Case Preservation............................6 - 5. Internationalized Domain Names..........................7 - 6. Security Considerations.................................8 - - Copyright and Disclaimer...................................9 - Normative References.......................................9 - Informative References....................................10 - - Changes Between Draft Version.............................11 - -02 to -03 Changes........................................11 - -03 to -04 Changes........................................11 - -04 to -05 Changes........................................11 - -05 to -06 Changes........................................12 - - Author's Address..........................................13 - Expiration and File Name..................................13 - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT DNS Case Insensitivity - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information. Each node in the DNS tree has a name consisting of - zero or more labels [STD 13][RFC 1591, 2606] that are treated in a - case insensitive fashion. This document clarifies the meaning of - "case insensitive" for the DNS. This clarification updates RFCs 1034 - and 1035 [STD 13]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - - -2. Case Insensitivity of DNS Labels - - DNS was specified in the era of [ASCII]. DNS names were expected to - look like most host names or Internet email address right halves (the - part after the at-sign, "@") or be numeric as in the in-addr.arpa - part of the DNS name space. For example, - - foo.example.net. - aol.com. - www.gnu.ai.mit.edu. - or 69.2.0.192.in-addr.arpa. - - Case varied alternatives to the above would be DNS names like - - Foo.ExamplE.net. - AOL.COM. - WWW.gnu.AI.mit.EDU. - or 69.2.0.192.in-ADDR.ARPA. - - However, the individual octets of which DNS names consist are not - limited to valid ASCII character codes. They are 8-bit bytes and all - values are allowed. Many applications, however, interpret them as - ASCII characters. - - - -2.1 Escaping Unusual DNS Label Octets - - In Master Files [STD 13] and other human readable and writable ASCII - contexts, an escape is needed for the byte value for period (0x2E, - ".") and all octet values outside of the inclusive range of 0x21 - ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in - the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT DNS Case Insensitivity - - - One typographic convention for octets that do not correspond to an - ASCII printing graphic is to use a back-slash followed by the value - of the octet as an unsigned integer represented by exactly three - decimal digits. - - The same convention can be used for printing ASCII characters so that - they will be treated as a normal label character. This includes the - back-slash character used in this convention itself which can be - expressed as \092 or \\ and the special label separator period (".") - which can be expressed as and \046 or \. respectively. It is - advisable to avoid using a backslash to quote an immediately - following non-printing ASCII character code to avoid implementation - difficulties. - - A back-slash followed by only one or two decimal digits is undefined. - A back-slash followed by four decimal digits produces two octets, the - first octet having the value of the first three digits considered as - a decimal number and the second octet being the character code for - the fourth decimal digit. - - - -2.2 Example Labels with Escapes - - The first example below shows embedded spaces and a period (".") - within a label. The second one show a 5-octet label where the second - octet has all bits zero, the third is a backslash, and the fourth - octet has all bits one. - - Donald\032E\.\032Eastlake\0323rd.example. - and a\000\\\255z.example. - - - -3. Name Lookup, Label Types, and CLASS - - The original DNS design decision was made that comparisons on name - lookup for DNS queries should be case insensitive [STD 13]. That is - to say, a lookup string octet with a value in the inclusive range of - 0x41 to 0x5A, the upper case ASCII letters, MUST match the identical - value and also match the corresponding value in the inclusive range - 0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet - with a lower case ASCII letter value MUST similarly match the - identical value and also match the corresponding value in the upper - case ASCII letter range. - - (Historical Note: the terms "upper case" and "lower case" were - invented after movable type. The terms originally referred to the - two font trays for storing, in partitioned areas, the different - physical type elements. Before movable type, the nearest equivalent - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT DNS Case Insensitivity - - - terms were "majuscule" and "minuscule".) - - One way to implement this rule would be, when comparing octets, to - subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A - before the comparison. Such an operation is commonly known as "case - folding" but implementation via case folding is not required. Note - that the DNS case insensitivity does NOT correspond to the case - folding specified in [iso-8859-1] or [iso-8859-2]. For example, the - octets 0xDD (\221) and 0xFD (\253) do NOT match although in other - contexts, where they are interpreted as the upper and lower case - version of "Y" with an acute accent, they might. - - - -3.1 Original DNS Label Types - - DNS labels in wire-encoded names have a type associated with them. - The original DNS standard [RFC 1035] had only two types. ASCII - labels, with a length of from zero to 63 octets, and indirect (or - compression) labels which consist of an offset pointer to a name - location elsewhere in the wire encoding on a DNS message. (The ASCII - label of length zero is reserved for use as the name of the root node - of the name tree.) ASCII labels follow the ASCII case conventions - described herein and, as stated above, can actually contain arbitrary - byte values. Indirect labels are, in effect, replaced by the name to - which they point which is then treated with the case insensitivity - rules in this document. - - - -3.2 Extended Label Type Case Insensitivity Considerations - - DNS was extended by [RFC 2671] to have additional label type numbers - available. (The only such type defined so far is the BINARY type [RFC - 2673] which is now Experimental [RFC 3363].) - - The ASCII case insensitivity conventions only apply to ASCII labels, - that is to say, label type 0x0, whether appearing directly or invoked - by indirect labels. - - - -3.3 CLASS Case Insensitivity Considerations - - As described in [STD 13] and [RFC 2929], DNS has an additional axis - for data location called CLASS. The only CLASS in global use at this - time is the "IN" or Internet CLASS. - - The handling of DNS label case is not CLASS dependent. With the - original design of DNS, it was intended that a recursive DNS resolver - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT DNS Case Insensitivity - - - be able to handle new CLASSes that were unknown at the time of its - implementation. This requires uniform handling of label case - insensitivity. Should it become desireable, for example, to allocate - a CLASS with "case sensitive ASCII labels" for example, it would be - necessary to allocate a new label type for these labels. - - - -4. Case on Input and Output - - While ASCII label comparisons are case insensitive, [STD 13] says - case MUST be preserved on output, and preserved when convenient on - input. However, this means less than it would appear since the - preservation of case on output is NOT required when output is - optimized by the use of indirect labels, as explained below. - - - -4.1 DNS Output Case Preservation - - [STD 13] views the DNS namespace as a node tree. ASCII output is as - if a name was marshaled by taking the label on the node whose name is - to be output, converting it to a typographically encoded ASCII - string, walking up the tree outputting each label encountered, and - preceding all labels but the first with a period ("."). Wire output - follows the same sequence but each label is wire encoded and no - periods inserted. No "case conversion" or "case folding" is done - during such output operations, thus "preserving" case. However, to - optimize output, indirect labels may be used to point to names - elsewhere in the DNS answer. In determining whether the name to be - pointed to, for example the QNAME, is the "same" as the remainder of - the name being optimized, the case insensitive comparison specified - above is done. Thus such optimization may easily destroy the output - preservation of case. This type of optimization is commonly called - "name compression". - - - -4.2 DNS Input Case Preservation - - Originally, DNS data came from an ASCII Master File as defined in - [STD 13] or a zone transfer. DNS Dynamic update and incremental zone - transfers [RFC 1995] have been added as a source of DNS data [RFC - 2136, 3007]. When a node in the DNS name tree is created by any of - such inputs, no case conversion is done. Thus the case of ASCII - labels is preserved if they are for nodes being created. However, - when a name label is input for a node that already exist in DNS data - being held, the situation is more complex. Implementations are free - to retain the case first loaded for such a label or allow new input - to override the old case or even maintain separate copies preserving - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT DNS Case Insensitivity - - - the input case. - - For example, if data with owner name "foo.bar.example" is loaded and - then later data with owner name "xyz.BAR.example" is input, the name - of the label on the "bar.example" node, i.e. "bar", might or might - not be changed to "BAR" in the DNS stored data or the actual input - case could be preserved. Thus later retrieval of data stored under - "xyz.bar.example" in this case can return all data with - "xyz.BAR.example" or all data with "xyz.bar.example" or even, when - more than one RR is being returned, a mixture of these two cases. - This last case is unlikely because optimization of answer length - through indirect labels tends to cause only copy of the name tail - ("bar.example" or "BAR.example") to be used for all returned RRs. - Note that none of this has any effect on the number of completeness - of the RR set returned, only on the case of the names in the RR set - returned. - - The same considerations apply when inputting multiple data records - with owner names differing only in case. For example, if an "A" - record is the first resourced record stored under owner name - "xyz.BAR.example" and then a second "A" record is stored under - "XYZ.BAR.example", the second MAY be stored with the first (lower - case initial label) name or the second MAY override the first so that - only an upper case initial label is retained or both capitalizations - MAY be kept in the DNS stored data. In any case, a retrieval with - either capitalization will retrieve all RRs with either - capitalization. - - Note that the order of insertion into a server database of the DNS - name tree nodes that appear in a Master File is not defined so that - the results of inconsistent capitalization in a Master File are - unpredictable output capitalization. - - - -5. Internationalized Domain Names - - A scheme has been adopted for "internationalized domain names" and - "internationalized labels" as described in [RFC 3490, 3454, 3491, and - 3492]. It makes most of [UNICODE] available through a separate - application level transformation from internationalized domain name - to DNS domain name and from DNS domain name to internationalized - domain name. Any case insensitivity that internationalized domain - names and labels have varies depending on the script and is handled - entirely as part of the transformation described in [RFC 3454] and - [RFC 3491] which should be seen for further details. This is not a - part of the DNS as standardized in STD 13. - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT DNS Case Insensitivity - - -6. Security Considerations - - The equivalence of certain DNS label types with case differences, as - clarified in this document, can lead to security problems. For - example, a user could be confused by believing two domain names - differing only in case were actually different names. - - Furthermore, a domain name may be used in contexts other than the - DNS. It could be used as a case sensitive index into some data base - or file system. Or it could be interpreted as binary data by some - integrity or authentication code system. These problems can usually - be handled by using a standardized or "canonical" form of the DNS - ASCII type labels, that is, always mapping the ASCII letter value - octets in ASCII labels to some specific pre-chosen case, either upper - case or lower case. An example of a canonical form for domain names - (and also a canonical ordering for them) appears in Section 6 of [RFC - 4034]. See also [RFC 3597]. - - Finally, a non-DNS name may be stored into DNS with the false - expectation that case will always be preserved. For example, although - this would be quite rare, on a system with case sensitive email - address local parts, an attempt to store two "RP" records that - differed only in case would probably produce unexpected results that - might have security implications. That is because the entire email - address, including the possibly case sensitive local or left hand - part, is encoded into a DNS name in a readable fashion where the case - of some letters might be changed on output as described above. - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Copyright and Disclaimer - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Normative References - - [ASCII] - ANSI, "USA Standard Code for Information Interchange", - X3.4, American National Standards Institute: New York, 1968. - - [RFC 1034, 1035] - See [STD 13]. - - [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August - 1996. - - [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997. - - [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. - - [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic - Update", November 2000. - - [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", - draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. - - [RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [STD 13] - - P. Mockapetris, "Domain names - concepts and facilities", RFC - 1034, November 1987. - - P. Mockapetris, "Domain names - implementation and - specification", RFC 1035, November 1987. - - - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Informative References - - [ISO 8859-1] - International Standards Organization, Standard for - Character Encodings, Latin-1. - - [ISO 8859-2] - International Standards Organization, Standard for - Character Encodings, Latin-2. - - [RFC 1591] - J. Postel, "Domain Name System Structure and - Delegation", March 1994. - - [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", - June 1999. - - [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain - Name System (DNS) IANA Considerations", September 2000. - - [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August - 1999. - - [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", - August 1999. - - [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of - Foo", 1 April 2001. - - [RFC 3363] - 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. - - [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of - Internationalized String ("stringprep")", December 2002. - - [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", March 2003. - - [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile - for Internationalized Domain Names (IDN)", March 2003. - - [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode - for Internationalized Domain Names in Applications (IDNA)", March - 2003. - - [UNICODE] - The Unicode Consortium, "The Unicode Standard", - <http://www.unicode.org/unicode/standard/standard.html>. - - - - - - - -D. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Changes Between Draft Version - - RFC Editor: The following summaries of changes between draft versions - are to be removed before publication. - - - --02 to -03 Changes - - The following changes were made between draft version -02 and -03: - - 1. Add internationalized domain name section and references. - - 2. Change to indicate that later input of a label for an existing DNS - name tree node may or may not be normalized to the earlier input or - override it or both may be preserved. - - 3. Numerous minor wording changes. - - - --03 to -04 Changes - - The following changes were made between draft versions -03 and -04: - - 1. Change to conform to the new IPR, Copyright, etc., notice - requirements. - - 2. Change in some section headers for clarity. - - 3. Drop section on wildcards. - - 4. Add emphasis on loss of case preservation due to name compression. - - 5. Add references to RFCs 1995 and 3092. - - - --04 to -05 Changes - - The following changes were made between draft versions -04 and -05: - - 1. More clearly state that this draft updates RFCs 1034, 1035 [STD - 13]. - - 2. Add informative references to ISO 8859-1 and ISO 8859-2. - - 3. Fix hyphenation and capitalization nits. - - - - -D. Eastlake 3rd [Page 11] - - -INTERNET-DRAFT DNS Case Insensitivity - - --05 to -06 Changes - - The following changes were made between draft version -05 and -06. - - 1. Add notation to the RFC Editor that the draft version change - summaries are to be removed before RFC publication. - - 2. Additional text explaining why labe case insensitivity is CLASS - independent. - - 3. Changes and additional text clarifying that the fact that - inconsistent case in data loaded into DNS may result in - unpredicatable or inconsistent case in DNS storage but has no effect - on the completeness of RR sets retrieved. - - 4. Add reference to [RFC 3363] and update reference to [RFC 2535] to - be to [RFC 4034]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 12] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1 508-786-7554 (w) - - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires January 2006. - - Its file name is draft-ietf-dnsext-insensitive-06.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 13] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt deleted file mode 100644 index cc3c276..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt +++ /dev/null @@ -1,2072 +0,0 @@ - - - -Network Working Group B. Laurie -Internet-Draft G. Sisson -Expires: December 3, 2005 Nominet - R. Arends - Telematica Instituut - june 2005 - - - DNSSEC Hash Authenticated Denial of Existence - draft-ietf-dnsext-nsec3-02 - -Status of this Memo - - 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 becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - 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 December 3, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be - used to provide authenticated denial of existence of DNS ownernames - and types; however, it permits any user to traverse a zone and obtain - a listing of all ownernames. - - A complete zone file can be used either directly as a source of - - - -Laurie, et al. Expires December 3, 2005 [Page 1] - -Internet-Draft nsec3 june 2005 - - - probable e-mail addresses for spam, or indirectly as a key for - multiple WHOIS queries to reveal registrant data which many - registries (particularly in Europe) may be under strict legal - obligations to protect. Many registries therefore prohibit copying - of their zone file; however the use of NSEC RRs renders policies - unenforceable. - - This document proposes a scheme which obscures original ownernames - while permitting authenticated denial of existence of non-existent - names. Non-authoritative delegation point NS RR types may be - excluded. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 - 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5 - 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6 - 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6 - 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 7 - 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 7 - 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 7 - 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7 - 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 8 - 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 9 - 3. Creating Additional NSEC3 RRs for Empty Non Terminals . . . . 9 - 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 10 - 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 10 - 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 11 - 6.1 Delegation Points . . . . . . . . . . . . . . . . . . . . 11 - 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11 - 6.2 Proving Nonexistence . . . . . . . . . . . . . . . . . . . 12 - 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 13 - 6.4.1 Avoiding Hash Collisions during generation . . . . . . 14 - 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 14 - 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 14 - 7. Performance Considerations . . . . . . . . . . . . . . . . . . 15 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16 - 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 - A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 18 - - - -Laurie, et al. Expires December 3, 2005 [Page 2] - -Internet-Draft nsec3 june 2005 - - - B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 23 - B.1 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - B.1.1 Authenticating the Example DNSKEY RRset . . . . . . . 25 - B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 26 - B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 28 - B.3.1 No Data Error, Empty Non-Terminal . . . . . . . . . . 29 - B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 30 - B.5 Referral to Unsigned Zone using Opt-In . . . . . . . . . . 31 - B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 32 - B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 34 - B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 35 - Intellectual Property and Copyright Statements . . . . . . . . 37 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 3] - -Internet-Draft nsec3 june 2005 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduced the NSEC Resource - Record (RR) for authenticated denial of existence. This document - introduces a new RR as an alternative to NSEC that provides measures - against zone traversal and allows for gradual expansion of - delegation-centric zones. - -1.1 Rationale - - The DNS Security Extensions included the NSEC RR to provide - authenticated denial of existence. Though the NSEC RR meets the - requirements for authenticated denial of existence, it introduced a - side-effect in that the contents of a zone can be enumerated. This - property introduces undesired policy issues. - - A second problem was the requirement that the existence of all record - types in a zone - including delegation point NS record types - must - be accounted for, despite the fact that delegation point NS RRsets - are not authoritative and not signed. This requirement has a side- - effect that the overhead of delegation-centric signed zones is not - related to the increase in security of subzones. This requirement - does not allow delegation-centric zones size to grow in relation to - the growth of signed subzones. - - In the past, solutions have been proposed as a measure against these - side effects but at the time were regarded as secondary over the need - to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter) - a graceful transition path to future enhancements is introduced, - while current DNSSEC deployment can continue. This document presents - the NSEC3 Resource Record which mitigates these issues with the NSEC - RR. - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs - that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 - [RFC2308]. - -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 Terminology - - In this document the term "original ownername" refers to a standard - ownername. Because this proposal uses the result of a hash function - - - -Laurie, et al. Expires December 3, 2005 [Page 4] - -Internet-Draft nsec3 june 2005 - - - over the original (unmodified) ownername, this result is referred to - as "hashed ownername". - - "Canonical ordering of the zone" means the order in which hashed - ownernames are arranged according to their numerical value, treating - the leftmost (lowest numbered) byte as the most significant byte. - -2. The NSEC3 Resource Record - - The NSEC3 RR provides Authenticated Denial of Existence for DNS - Resource Record Sets. - - The NSEC3 Resource Record lists RR types present at the NSEC3 RR's - original ownername. It includes the next hashed ownername in the - canonical ordering of the zone. The complete set of NSEC3 RRs in a - zone indicates which RRsets exist for the original ownername of the - RRset and form a chain of hashed ownernames in the zone. This - information is used to provide authenticated denial of existence for - DNS data, as described in RFC 4035 [RFC4035]. Unsigned delegation - point NS RRsets can optionally be excluded. To provide protection - against zone traversal, the ownernames used in the NSEC3 RR are - cryptographic hashes of the original ownername prepended to the name - of the zone. The NSEC3 RR indicates which hash function is used to - construct the hash, which salt is used, and how many iterations of - the hash function are performed over the original ownername. - - The ownername for the NSEC3 RR is the base32 encoding of the hashed - ownername. - - The type value for the NSEC3 RR is XX. - - The NSEC3 RR RDATA format is class independent. - - The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [RFC2308]. - -2.1 NSEC3 RDATA Wire Format - - The RDATA of the NSEC3 RR is as shown below: - - - - - - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 5] - -Internet-Draft nsec3 june 2005 - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |A|Hash Function| Iterations | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Salt Length | Salt / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Hashed Ownername / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -2.1.1 The Authoritative Only Flag Field - - The Authoritative Only Flag field indicates whether the Type Bit Maps - include delegation point NS record types. - - If the flag is set to 1, the NS RR type bit for a delegation point - ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR - type bit MUST be ignored during processing of the NSEC3 RR. The NS - RR type bit has no meaning in this context (it is not authoritative), - hence the NSEC3 does not contest the existence of a NS RRset for this - ownername. When a delegation is not secured, there exist no DS RR - type nor any other authoritative types for this delegation, hence the - unsecured delegation has no NSEC3 record associated. Please see the - Special Consideration section for implications for unsigned - delegations. - - If the flag is set to 0, the NS RR type bit for a delegation point - ownername MUST be set if the NSEC3 covers a delegation, even though - the NS RR itself is not authoritative. This implies that all - delegations, signed or unsigned, have an NSEC3 record associated. - This behaviour is identical to NSEC behaviour. - -2.1.2 The Hash Function Field - - The Hash Function field identifies the cryptographic hash function - used to construct the hash-value. - - This document defines Value 1 for SHA-1 and Value 127 for - experimental. All other values are reserved. - - On reception, a resolver MUST discard an NSEC3 RR with an unknown - hash function value. - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 6] - -Internet-Draft nsec3 june 2005 - - -2.1.3 The Iterations Field - - The Iterations field defines the number of times the hash has been - iterated. More iterations results in greater resiliency of the hash - value against dictionary attacks, but at a higher cost for both the - server and resolver. - -2.1.4 The Salt Length Field - - The salt length field defines the length of the salt in octets. - -2.1.5 The Salt Field - - The Salt field is not present when the Salt Length Field has a value - of 0. - - The Salt field is prepended to the original ownername before hashing - in order to defend against precalculated dictionary attacks. - - The salt is also prepended during iterations of the hash function. - - Note that although it is theoretically possible to cover the entire - possible ownername space with different salt values, it is - computationally infeasible to do so, and so there MUST be at least - one salt which is the same for all NSEC3 records. This means that no - matter what name is asked for in a query, it is guaranteed to be - possible to find a covering NSEC3 record. Note that this does not - preclude the use of two different salts at the same time - indeed - this may well occur naturally, due to rolling the salt value - periodically. - - The salt value SHOULD be changed from time to time - this is to - prevent the use of a precomputed dictionary to reduce the cost of - enumeration. - -2.1.6 The Next Hashed Ownername Field - - The Next Hashed Ownername field contains the hash of the ownername of - the next RR in the canonical ordering of the hashed ownernames of the - zone. The value of the Next Hashed Ownername Field in the last NSEC3 - record in the zone is the same as the ownername of the first NSEC3 RR - in the zone in canonical order. - - Hashed ownernames of RRsets not authoritative for the given zone - (such as glue records) MUST NOT be listed in the Next Hashed - Ownername unless at least one authoritative RRset exists at the same - ownername. - - - - -Laurie, et al. Expires December 3, 2005 [Page 7] - -Internet-Draft nsec3 june 2005 - - - Note that the Next Hashed Ownername field is not encoded, unlike the - NSEC3 RR's ownername. It is the unmodified binary hash value. - -2.1.7 The list of Type Bit Map(s) Field - - The Type Bit Maps field identifies the RRset types which exist at the - NSEC3 RR's ownername. - - The Type bits for the NSEC3 RR and RRSIG RR MUST be set during - generation, and MUST be ignored during processing. - - 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 NSEC3 RR RDATA in increasing numerical - order. - - "|" denotes concatenation - - Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRset of that type is present for the NSEC3 - RR's ownername. If a bit is set to 0, it indicates that no RRset of - that type is present for the NSEC3 RR's ownername. - - The RR type 2 (NS) is authoritative at the apex of a zone and is not - authoritative at delegation points. If the Authoritative Only Flag - is set to 1, the delegation point NS RR type MUST NOT be included in - the type bit maps. If the Authoritative Only Flag is set to 0, the - NS RR type at a delegation point MUST be included in the type bit - maps. - - Since bit 0 in window block 0 refers to the non-existing RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 - [RFC2929] (section 3.1) or within the range reserved for assignment - only to QTYPEs and Meta-TYPEs MUST be set to 0, since they do not - - - -Laurie, et al. Expires December 3, 2005 [Page 8] - -Internet-Draft nsec3 june 2005 - - - 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 - NSEC3 RR's actual ownername. Trailing zero octets not specified MUST - be interpreted as zero octets. - -2.2 The NSEC3 RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Authoritative Only Field is represented as an unsigned decimal - integer. The value are either 0 or 1. - - The Hash field is presented as the name of the hash or as an unsigned - decimal integer. The value has a maximum of 127. - - The Iterations field is presented as an unsigned decimal integer. - - The Salt Length field is not presented. - - The Salt field is represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is not allowed within the sequence. - The Salt Field is represented as 00 when the Salt Length field has - value 0. - - The Next Hashed Ownername field is represented as a sequence of case- - insensitive base32 digits. Whitespace is allowed within the - sequence. - - The List of Type Bit Map(s) Field is represented as a sequence of RR - type mnemonics. When the mnemonic is not known, the TYPE - representation as described in RFC 3597 [RFC3597] (section 5) MUST be - used. - -3. Creating Additional NSEC3 RRs for Empty Non Terminals - - In order to prove the non-existence of a record that might be covered - by a wildcard, it is necessary to prove the existence of its closest - encloser. A closest encloser might be an Empty Non Terminal. - - Additional NSEC3 RRs are synthesized which cover every existing - intermediate label level. Additional NSEC3 RRs are identical in - format to NSEC3 RRs that cover existing RRs in the zone. The - difference is that the type-bit-maps only indicate the existence of - - - -Laurie, et al. Expires December 3, 2005 [Page 9] - -Internet-Draft nsec3 june 2005 - - - an NSEC3 RR type and an RRSIG RR type. - -4. Calculation of the Hash - - Define H(x) to be the hash of x using the hash function selected by - the NSEC3 record and || to indicate concatenation. Then define: - - IH(salt,x,0)=H(x || salt) - - IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 - - Then the calculated hash of an ownername is - IH(salt,ownername,iterations-1), where the ownername is the canonical - form. - - The canonical form of the ownername is the wire format of the - ownername where: - 1. The ownername is fully expanded (no DNS name compression) and - fully qualified; - 2. All uppercase US-ASCII letters are replaced by the corresponding - lowercase US-ASCII letters; - 3. If the ownername is a wildcard name, the ownername is in its - original unexpanded form, including the "*" label (no wildcard - substitution); - -5. Including NSEC3 RRs in a Zone - - Each owner name in the zone which has authoritative data or a secured - delegation point NS RRset MUST have an NSEC3 resource record. - - An unsecured delegation point NS RRset MAY have an NSEC3 resource - record. This is different from NSEC records where an unsecured - delegation point NS RRset MUST have an NSEC record. - - The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL - value field in the zone SOA RR. - - The type bitmap of every NSEC3 resource record in a signed zone MUST - indicate the presence of both the NSEC3 RR type itself and its - corresponding RRSIG RR type. - - The bitmap for the NSEC3 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. - - The following steps describe the proper construction of NSEC3 - - - -Laurie, et al. Expires December 3, 2005 [Page 10] - -Internet-Draft nsec3 june 2005 - - - records. - 1. For each unique original owner name in the zone, add an NSEC3 - RRset. This includes NSEC3 RRsets for unsigned delegation point - NS RRsets, unless the policy is to have Authoritative Only NSEC3 - RRsets. The ownername of the NSEC3 RR is the hashed equivalent - of the original owner name, prepended to the zone name. - 2. For each RRset at the original owner, set the corresponding bit - in the type bit map. - 3. If the difference in number of labels between the apex and the - original ownername is greater then 1, additional NSEC3s need to - be added for every empty non-terminal between the apex and the - original ownername. - 4. Sort the set of NSEC3 RRs. - 5. In each NSEC3 RR, insert the Next Hashed Ownername. The Next - Hashed Ownername of the last NSEC3 in the zone contains the value - of the hashed ownername of the first NSEC3 in the zone. - 6. If the policy is to have authoritative only, set the - Authoritative Only bit in those NSEC3 RRs that cover unsecured - delegation points. - -6. Special Considerations - - The following paragraphs clarify specific behaviour explain special - considerations for implementations. - -6.1 Delegation Points - - This proposal introduces the Authoritative Only Flag which indicates - whether non authoritative delegation point NS records are included in - the type bit Maps. As discussed in paragraph 2.1.1, a flag value of - 0 indicates that the interpretation of the type bit maps is identical - to NSEC records. - - The following subsections describe behaviour when the flag value is - 1. - -6.1.1 Unsigned Delegations - - Delegation point NS records are not authoritative. They are - authoritative in the delegated zone. No other data exists at the - ownername of an unsigned delegation point. - - Since no authoritative data exist at this ownername, it is excluded - from the NSEC3 chain. This is an optimization, since it relieves the - zone of including an NSEC3 record and its associated signature for - this name. - - An NSEC3 that denies existence of ownernames between X and X' with - - - -Laurie, et al. Expires December 3, 2005 [Page 11] - -Internet-Draft nsec3 june 2005 - - - the Authoritative Only Flag set to 1 can not be used to prove the - presence or the absence of delegation point NS records for unsigned - delegations in the interval (X, X'). The Authoritative Only Flag - effectively states No Contest on the presence of delegation point NS - resource records. - - Since proof is absent, there exists a new attack vector. Unsigned - delegation point NS records can be deleted during a man in the middle - attack, effectively denying existence of the delegation. This is a - form of Denial of Service, where the victim has no information it is - under attack, since all signatures are valid and the fabricated - response form is a known type of response. - - The only possible mitigation is to either not use this method, hence - proving existence or absence of unsigned delegations, or to sign all - delegations, regardless of whether the delegated zone is signed or - not. - - A second attack vector exists in that an adversary is able to - successfully fabricate an (unsigned) response claiming a nonexistent - delegation exists. - - The only possible mitigation is to mandate the signing of all - delegations. - -6.2 Proving Nonexistence - - If a wildcard resource record appears in a zone, its asterisk label - is treated as a literal symbol and is treated in the same way as any - other ownername for purposes of generating NSEC3 RRs. RFC 4035 - [RFC4035] describes the impact of wildcards on authenticated denial - of existence. - - In order to prove there exist no RRs for a domain, as well as no - source of synthesis, an RR must be shown for the closest encloser, - and non-existence must be shown for all closer labels and for the - wildcard at the closest encloser. - - This can be done as follows. If the QNAME in the query is - omega.alfa.beta.example, and the closest encloser is beta.example - (the nearest ancestor to omega.alfa.beta.example), then the server - should return an NSEC3 that demonstrates the nonexistence of - alfa.beta.example, an NSEC3 that demonstrates the nonexistence of - *.beta.example, and an NSEC3 that demonstrates the existence of - beta.example. This takes between one and three NSEC3 records, since - a single record can, by chance, prove more than one of these facts. - - When a verifier checks this response, then the existence of - - - -Laurie, et al. Expires December 3, 2005 [Page 12] - -Internet-Draft nsec3 june 2005 - - - beta.example together with the non-existence of alfa.beta.example - proves that the closest encloser is indeed beta.example. The non- - existence of *.beta.example shows that there is no wildcard at the - closest encloser, and so no source of synthesis for - omega.alfa.beta.example. These two facts are sufficient to satisfy - the resolver that the QNAME cannot be resolved. - - In practice, since the NSEC3 owner and next names are hashed, if the - server responds with an NSEC3 for beta.example, the resolver will - have to try successively longer names, starting with example, moving - to beta.example, alfa.beta.example, and so on, until one of them - hashes to a value that matches the interval (but not the ownername - nor next owner name) of one of the returned NSEC3s (this name will be - alfa.beta.example). Once it has done this, it knows the closest - encloser (i.e. beta.example), and can then easily check the other two - required proofs. - - Note that it is not possible for one of the shorter names tried by - the resolver to be denied by one of the returned NSEC3s, since, by - definition, all these names exist and so cannot appear within the - range covered by an NSEC3. Note, however, that the first name that - the resolver tries MUST be the apex of the zone, since names above - the apex could be denied by one of the returned NSEC3s. - -6.3 Salting - - Augmenting original ownernames with salt before hashing increases the - cost of a dictionary of pre-generated hash-values. For every bit of - salt, the cost of the dictionary doubles. The NSEC3 RR can use a - maximum of 2040 bits of salt, multiplying the cost by 2^2040. - - There MUST be a complete set of NSEC3s for the zone using the same - salt value. The salt value for each NSEC3 RR MUST be equal for a - single version of the zone. - - The salt SHOULD be changed every time the zone is resigned to prevent - precomputation using a single salt. - -6.4 Hash Collision - - Hash collisions occur when different messages have the same hash - value. The expected number of domain names needed to give a 1 in 2 - chance of a single collision is about 2^(n/2) for a hash of length n - bits (i.e. 2^80 for SHA-1). Though this probability is extremely - low, the following paragraphs deal with avoiding collisions and - assessing possible damage in the event of an attack using hash - collisions. - - - - -Laurie, et al. Expires December 3, 2005 [Page 13] - -Internet-Draft nsec3 june 2005 - - -6.4.1 Avoiding Hash Collisions during generation - - During generation of NSEC3 RRs, hash values are supposedly unique. - In the (academic) case of a collision occurring, an alternative salt - SHOULD be chosen and all hash values SHOULD be regenerated. - - If hash values are not regenerated on collision, the NSEC3 RR MUST - list all authoritative RR types that exist for both owners, to avoid - a replay attack, spoofing an existing type as non-existent. - -6.4.2 Second Preimage Requirement Analysis - - A cryptographic hash function has a second-preimage resistance - property. The second-preimage resistance property means that it is - computationally infeasible to find another message with the same hash - value as a given message, i.e. given preimage X, to find a second - preimage X' <> X such that hash(X) = hash(X'). The work factor for - finding a second preimage is of the order of 2^160 for SHA-1. To - mount an attack using an existing NSEC3 RR, an adversary needs to - find a second preimage. - - Assuming an adversary is capable of mounting such an extreme attack, - the actual damage is that a response message can be generated which - claims that a certain QNAME (i.e. the second pre-image) does exist, - while in reality QNAME does not exist (a false positive), which will - either cause a security aware resolver to re-query for the non- - existent name, or to fail the initial query. Note that the adversary - can't mount this attack on an existing name but only on a name that - the adversary can't choose and does not yet exist. - -6.4.3 Possible Hash Value Truncation Method - - The previous sections outlined the low probability and low impact of - a second-preimage attack. When impact and probability are low, while - space in a DNS message is costly, truncation is tempting. Truncation - might be considered to allow for shorter ownernames and rdata for - hashed labels. In general, if a cryptographic hash is truncated to n - bits, then the expected number of domains required to give a 1 in 2 - probability of a single collision is approximately 2^(n/2) and the - work factor to produce a second preimage resistance is 2^n. - - An extreme hash value truncation would be truncating to the shortest - possible unique label value. Considering that hash values are - presented in base32, which represents 5 bits per label character, - truncation must be done on a 5 bit boundary. This would be unwise, - since the work factor to produce collisions would then approximate - the size of the zone. - - - - -Laurie, et al. Expires December 3, 2005 [Page 14] - -Internet-Draft nsec3 june 2005 - - - Though the mentioned truncation can be maximized to a certain - extreme, the probability of collision increases exponentially for - every truncated bit. Given the low impact of hash value collisions - and limited space in DNS messages, the balance between truncation - profit and collision damage may be determined by local policy. Of - course, the size of the corresponding RRSIG RR is not reduced, so - truncation is of limited benefit. - - Truncation could be signalled simply by reducing the length of the - first label in the ownername. Note that there would have to be a - corresponding reduction in the length of the Next Hashed Ownername - field. - -7. Performance Considerations - - Iterated hashes will obviously impose a performance penalty on both - authoritative servers and resolvers. Therefore, the number of - iterations should be carefully chosen. In particular it should be - noted that a high value for iterations gives an attacker a very good - denial of service attack, since the attacker need not bother to - verify the results of their queries, and hence has no performance - penalty of his own. - - On the other hand, nameservers with low query rates and limited - bandwidth are already subject to a bandwidth based denial of service - attack, since responses are typically an order of magnitude larger - than queries, and hence these servers may choose a high value of - iterations in order to increase the difficulty of offline attempts to - enumerate their namespace without significantly increasing their - vulnerability to denial of service attacks. - -8. IANA Considerations - - IANA has to create a new registry for NSEC3 Hash Functions. The - range for this registry is 0-127. Value 0 is the identity function. - Value 1 is SHA-1. Values 2-126 are Reserved For Future Use. Value - 127 is marked as Experimental. - -9. Security Considerations - - The NSEC3 records are still susceptible to dictionary attacks (i.e. - the attacker retrieves all the NSEC3 records, then calculates the - hashes of all likely domain names, comparing against the hashes found - in the NSEC3 records, and thus enumerating the zone). These are - substantially more expensive than traversing the original NSEC - records would have been, and in any case, such an attack could also - be used directly against the name server itself by performing queries - for all likely names, though this would obviously be more detectable. - - - -Laurie, et al. Expires December 3, 2005 [Page 15] - -Internet-Draft nsec3 june 2005 - - - The expense of this off-line attack can be chosen by setting the - number of iterations in the NSEC3 RR. - - High-value domains are also susceptible to a precalculated dictionary - attack - that is, a list of hashes for all likely names is computed - once, then NSEC3 is scanned periodically and compared against the - precomputed hashes. This attack is prevented by changing the salt on - a regular basis. - - Walking the NSEC3 RRs will reveal the total number of records in the - zone, and also what types they are. This could be mitigated by - adding dummy entries, but certainly an upper limit can always be - found. - - Hash collisions may occur. If they do, it will be impossible to - prove the non-existence of the colliding domain - however, this is - fantastically unlikely, and, in any case, DNSSEC already relies on - SHA-1 to not collide. - -10. References - -10.1 Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [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. - - [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, - "Domain Name System (DNS) IANA Considerations", BCP 42, - RFC 2929, September 2000. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - - -Laurie, et al. Expires December 3, 2005 [Page 16] - -Internet-Draft nsec3 june 2005 - - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -10.2 Informative References - - [I-D.ietf-dnsext-trustupdate-threshold] - Ihren, J., "An In-Band Rollover Mechanism and an Out-Of- - Band Priming Method for DNSSEC Trust Anchors.", - draft-ietf-dnsext-trustupdate-threshold-00 (work in - progress), October 2004. - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9, RFC 2026, October 1996. - - [RFC2418] Bradner, S., "IETF Working Group Guidelines and - Procedures", BCP 25, RFC 2418, September 1998. - - -Authors' Addresses - - Ben Laurie - Nominet - 17 Perryn Road - London W3 7LR - England - - Phone: +44 (20) 8735 0686 - Email: ben@algroup.co.uk - - - Geoffrey Sisson - Nominet - - - - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 17] - -Internet-Draft nsec3 june 2005 - - - Roy Arends - Telematica Instituut - Brouwerijstraat 1 - 7523 XC Enschede - The Netherlands - - Phone: +31 (53) 485 0485 - Email: roy.arends@telin.nl - -Appendix A. Example Zone - - This is a zone showing its NSEC3 records. They can also be used as - test vectors for the hash algorithm. - - - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 ) - 3600 RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - 3600 NS ns1.example. - 3600 NS ns2.example. - 3600 RRSIG NS 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l - m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d - 1SH5r/wfjuCg+g== ) - 3600 MX 1 xx.example. - 3600 RRSIG MX 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l - NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU - S/o/g5C8VM6ftQ== ) - 3600 DNSKEY 257 3 5 ( - AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX - cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 - zsYKWJ7BvR2894hX - ) ; Key ID = 21960 - 3600 DNSKEY 256 3 5 ( - AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU - 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL - ExXT48OGGdbfIme5 - - - -Laurie, et al. Expires December 3, 2005 [Page 18] - -Internet-Draft nsec3 june 2005 - - - ) ; Key ID = 62699 - 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z - xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx - mTkunTYzqWJrmQ== ) - 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( - 20050612112304 21960 example. - SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk - ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik - 3w7ZY2UWyYIvpw== ) - 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 ( - deadbeaf - 7nomf47k3vlidh4vxahhpp47l3tgv7a2 - NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5 - Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ - sb7KfbaUo/vzAg== ) - 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 ( - deadbeaf - dw4o7j64wnel3j4jh7fb3c5n7w3js2yb - MX NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA - ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo - MEFQmc/gEuxojA== ) - a.example. 3600 IN NS ns1.a.example. - 3600 IN NS ns2.a.example. - 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B - 766A6A4837206C ) - 3600 RRSIG DS 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn - cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 - 0kx7rGKTc3RQDA== ) - 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 20050712112304 ( - 20050612112304 62699 example. - plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU - 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq - ZXW5S+1VjMZYzQ== ) - 3600 HINFO "KLH-10" "ITS" - 3600 RRSIG HINFO 5 2 3600 20050712112304 ( - - - -Laurie, et al. Expires December 3, 2005 [Page 19] - -Internet-Draft nsec3 june 2005 - - - 20050612112304 62699 example. - AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk - tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg - VGNmbgPnqDVPiA== ) - 3600 AAAA 2001:db8:0:0:0:0:f00:baa9 - 3600 RRSIG AAAA 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV - ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns - l5/UqLCJJ9BDMg== ) - b.example. 3600 IN NS ns1.b.example. - 3600 IN NS ns2.b.example. - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 ( - deadbeaf - gmnfcccja7wkax3iv26bs75myptje3qk - MX DNSKEY NS SOA NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D - C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R - MOiKMSHozVebqw== ) - gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 ( - deadbeaf - jt4bbfokgbmr57qx4nqucvvn7fmo6ab6 - DS NS NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/ - ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW - OwQBGbOegrW/Zw== ) - jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 ( - deadbeaf - kcll7fqfnisuhfekckeeqnmbbd4maanu - NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V - IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK - 94Zbq3k8lgdpZA== ) - kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 ( - deadbeaf - n42hbhnjj333xdxeybycax5ufvntux5d - MX NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA - - - -Laurie, et al. Expires December 3, 2005 [Page 20] - -Internet-Draft nsec3 june 2005 - - - IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx - TOLtc5jPrkL4zQ== ) - n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 ( - deadbeaf - nimwfwcnbeoodmsc6npv3vuaagaevxxu - A NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy - 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj - xFPFGRIW3wKnrA== ) - nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 ( - deadbeaf - vhgwr2qgykdkf4m6iv6vkagbxozphazr - HINFO A AAAA NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx - z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG - jL33Wm1p07TBdw== ) - ns1.example. 3600 A 192.0.2.1 - 3600 RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb - BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr - nWWLepz1PjjShQ== ) - ns2.example. 3600 A 192.0.2.2 - 3600 RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 - P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz - AkeTJu3J3auUiA== ) - vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 ( - deadbeaf - wbyijvpnyj33pcpi3i44ecnibnaj7eiw - HINFO A AAAA NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W - kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M - 5SNSHIyfpfsi6A== ) - *.w.example. 3600 MX 1 ai.example. - 3600 RRSIG MX 5 3 3600 20050712112304 ( - 20050612112304 62699 example. - sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF - xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ - gQlgxEwhvQDEaQ== ) - x.w.example. 3600 MX 1 xx.example. - - - -Laurie, et al. Expires December 3, 2005 [Page 21] - -Internet-Draft nsec3 june 2005 - - - 3600 RRSIG MX 5 3 3600 20050712112304 ( - 20050612112304 62699 example. - s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w - lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP - U9VazOa1KEIq1w== ) - x.y.w.example. 3600 MX 1 xx.example. - 3600 RRSIG MX 5 4 3600 20050712112304 ( - 20050612112304 62699 example. - aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7 - uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF - 9VrQvJjwbllAfA== ) - wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 ( - deadbeaf - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui - A NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN - ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd - oorBv4xkb0flXw== ) - xx.example. 3600 A 192.0.2.10 - 3600 RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 - tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj - cxwCXWj82GVGdw== ) - 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q - OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk - KMf4DgNBDj+dIQ== ) - 3600 AAAA 2001:db8:0:0:0:0:f00:baaa - 3600 RRSIG AAAA 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo - w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy - rzKKwb8J04/ILw== ) - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 ( - deadbeaf - 5pe7ctl7pfs2cilroy5dcofx4rcnlypd - MX NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt - 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny - OcFlrPGPMm48/A== ) - - - - -Laurie, et al. Expires December 3, 2005 [Page 22] - -Internet-Draft nsec3 june 2005 - - -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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 23] - -Internet-Draft nsec3 june 2005 - - - ;; 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 IN RRSIG MX 5 3 3600 20050712112304 ( - 20050612112304 62699 example. - s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w - lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP - U9VazOa1KEIq1w== ) - - ;; Authority - example. 3600 IN NS ns1.example. - example. 3600 IN NS ns2.example. - example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l - m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d - 1SH5r/wfjuCg+g== ) - - ;; Additional - xx.example. 3600 IN A 192.0.2.10 - xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 - tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj - cxwCXWj82GVGdw== ) - xx.example. 3600 IN AAAA 2001:db8::f00:baaa - xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo - w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy - rzKKwb8J04/ILw== ) - ns1.example. 3600 IN A 192.0.2.1 - ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb - BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr - nWWLepz1PjjShQ== ) - ns2.example. 3600 IN A 192.0.2.2 - ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 - P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz - AkeTJu3J3auUiA== ) - - - - -Laurie, et al. Expires December 3, 2005 [Page 24] - -Internet-Draft nsec3 june 2005 - - - The query returned an MX RRset for "x.w.example". The corresponding - RRSIG RR indicates that the MX RRset was signed by an "example" - DNSKEY with algorithm 5 and key tag 62699. 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 RR 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 RR's labels field value of 3 indicates that the - answer was not the result of wildcard expansion. The "x.w.example" - MX RRset is placed in canonical form, and, assuming the current time - falls between the signature inception and expiration dates, the - signature is authenticated. - -B.1.1 Authenticating the Example DNSKEY RRset - - This example shows the logical authentication process that starts - from a configured root DNSKEY RRset (or DS RRset) and moves down the - tree to authenticate the desired "example" DNSKEY RRset. Note that - the logical order is presented for clarity. An implementation may - choose to construct the authentication as referrals are received or - 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 a configured DNSKEY RRset for the - root zone (or a configured DS RRset for the root zone). The resolver - checks whether this configured DNSKEY RRset is present in the root - DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY - RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the - root DNSKEY RRset, and whether 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 - that the resolver may have 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 - matching "example" DNSKEY is found, the resolver checks whether this - DNSKEY RR has signed the "example" DNSKEY RRset and the signature - lifetime is valid. If 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" - - - -Laurie, et al. Expires December 3, 2005 [Page 25] - -Internet-Draft nsec3 june 2005 - - - DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This - DNSKEY is used to authenticate 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 validate the signature as described above. - -B.2 Name Error - - An authoritative name error. The NSEC3 RRs prove that the name does - not exist and that no covering wildcard exists. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 26] - -Internet-Draft nsec3 june 2005 - - - ;; Header: QR AA DO RCODE=3 - ;; - ;; Question - a.c.x.w.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - dw4o7j64wnel3j4jh7fb3c5n7w3js2yb - MX NSEC3 RRSIG ) - 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA - ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo - MEFQmc/gEuxojA== ) - nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - vhgwr2qgykdkf4m6iv6vkagbxozphazr - HINFO A AAAA NSEC3 RRSIG ) - nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx - z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG - jL33Wm1p07TBdw== ) - ;; Additional - ;; (empty) - - The query returned two NSEC3 RRs that prove that the requested data - does not exist and no wildcard applies. The negative reply is - authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are - authenticated in a manner identical to that of the MX RRset discussed - - - -Laurie, et al. Expires December 3, 2005 [Page 27] - -Internet-Draft nsec3 june 2005 - - - above. At least one of the owner names of the NSEC3 RRs will match - the closest encloser. At least one of the NSEC3 RRs prove that there - exists no longer name. At least one of the NSEC3 RRs prove that - there exists no wildcard RRsets that should have been expanded. The - closest encloser can be found by hasing the apex ownername (The SOA - RR's ownername, or the ownername of the DNSKEY RRset referred by an - RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and - if that fails, continue by adding labels. - - In the above example, the name 'x.w.example' hashes to - '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might - be the closest encloser. To prove that 'c.x.w.example' and - '*.x.w.example' do not exists, these names are hashed to respectively - 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and - 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that - these hashed ownernames do not exists, since the names are within the - given intervals. - -B.3 No Data Error - - A "no data" response. The NSEC3 RR proves that the name exists and - that the requested RR type does not. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 28] - -Internet-Draft nsec3 june 2005 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - ns1.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui - A NSEC3 RRSIG ) - wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN - ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd - oorBv4xkb0flXw== ) - ;; Additional - ;; (empty) - - The query returned an NSEC3 RR that proves that the requested name - exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"), - but the requested RR type does not exist (type MX is absent in the - type code list of the NSEC RR). The negative reply is authenticated - by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner - identical to that of the MX RRset discussed above. - -B.3.1 No Data Error, Empty Non-Terminal - - A "no data" response because of an empty non-terminal. The NSEC3 RR - proves that the name exists and that the requested RR type does not. - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 29] - -Internet-Draft nsec3 june 2005 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - y.w.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - kcll7fqfnisuhfekckeeqnmbbd4maanu - NSEC3 RRSIG ) - jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V - IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK - 94Zbq3k8lgdpZA== ) - - The query returned an NSEC3 RR that proves that the requested name - exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"), - but the requested RR type does not exist (Type A is absent in the - type-bit-maps of the NSEC3 RR). The negative reply is authenticated - by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner - identical to that of the MX RRset discussed above. Note that, unlike - generic empty non terminal proof using NSECs, this is identical to - proving a No Data Error. This example is solely mentioned to be - complete. - -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. - - - - -Laurie, et al. Expires December 3, 2005 [Page 30] - -Internet-Draft nsec3 june 2005 - - - ;; 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 IN DS 58470 5 1 ( - 3079F1593EBAD6DC121E202A8B766A6A4837 - 206C ) - a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn - cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 - 0kx7rGKTc3RQDA== ) - - ;; Additional - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - - The query 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 whether - this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether - the signature lifetime is valid. If all these conditions are met, - all keys in the "a.example" DNSKEY RRset are considered - authenticated. - -B.5 Referral to Unsigned Zone using Opt-In - - Referral to an unsigned zone using Opt-In. The NSEC3 RR proves that - nothing for this delegation was signed in the parent zone. There is - no proof that the delegation exists - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 31] - -Internet-Draft nsec3 june 2005 - - - ;; 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. - kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 ( - deadbeaf - n42hbhnjj333xdxeybycax5ufvntux5d - MX NSEC3 RRSIG ) - kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA - IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx - TOLtc5jPrkL4zQ== ) - - ;; Additional - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - - The query returned a referral to the unsigned "b.example." zone. The - NSEC3 proves that no authentication leads from "example" to - "b.example", since the hash of "b.example" - ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and - the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a - manner identical to that of the MX RRset discussed above. - -B.6 Wildcard Expansion - - A successful query that 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 NSEC3 RR proves that - no closer match exists in the zone. - - - - - - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 32] - -Internet-Draft nsec3 june 2005 - - - ;; 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 IN RRSIG MX 5 3 3600 20050712112304 ( - 20050612112304 62699 example. - sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF - xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ - gQlgxEwhvQDEaQ== ) - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l - m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d - 1SH5r/wfjuCg+g== ) - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - 5pe7ctl7pfs2cilroy5dcofx4rcnlypd - MX NSEC3 RRSIG ) - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt - 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny - OcFlrPGPMm48/A== ) - ;; Additional - ai.example. 3600 IN A 192.0.2.9 - ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU - 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq - ZXW5S+1VjMZYzQ== ) - ai.example. 3600 AAAA 2001:db8::f00:baa9 - ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV - ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns - l5/UqLCJJ9BDMg== ) - - The query returned an answer that was produced as a result of - wildcard expansion. The answer section contains a wildcard RRset - expanded as it would be in a traditional DNS response, and the - corresponding RRSIG indicates that the expanded wildcard MX RRset was - - - -Laurie, et al. Expires December 3, 2005 [Page 33] - -Internet-Draft nsec3 june 2005 - - - signed by an "example" DNSKEY with algorithm 5 and key tag 62699. - The RRSIG indicates that 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 that the answer - is the result of wildcard expansion, as the "a.z.w.example" name - contains 4 labels. The name "a.z.w.example" is replaced by - "*.w.example", the MX RRset is placed in canonical form, and, - assuming that the current time falls between the signature inception - and expiration dates, the signature is authenticated. - - The NSEC3 proves that no closer match (exact or closer wildcard) - could have been used to answer this query, and the NSEC3 RR must also - be authenticated before the answer is considered valid. - -B.7 Wildcard No Data Error - - A "no data" response for a name covered by a wildcard. The NSEC3 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 34] - -Internet-Draft nsec3 june 2005 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - 5pe7ctl7pfs2cilroy5dcofx4rcnlypd - MX NSEC3 RRSIG ) - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt - 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny - OcFlrPGPMm48/A== ) - ;; Additional - ;; (empty) - - The query returned NSEC3 RRs that prove that the requested data does - not exist and no wildcard applies. The negative reply is - authenticated by verifying both NSEC3 RRs. - -B.8 DS Child Zone No Data Error - - A "no data" response for a QTYPE=DS query that was mistakenly sent to - a name server for the child zone. - - - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 35] - -Internet-Draft nsec3 june 2005 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - example. IN DS - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - gmnfcccja7wkax3iv26bs75myptje3qk - MX DNSKEY NS SOA NSEC3 RRSIG ) - dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D - C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R - MOiKMSHozVebqw== ) - - ;; Additional - ;; (empty) - - The query 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 that the answer is from the child . - Queries for the "example" DS RRset should be sent to the parent - servers ("root" servers). - - - - - - - - - - - -Laurie, et al. Expires December 3, 2005 [Page 36] - -Internet-Draft nsec3 june 2005 - - -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 (2005). 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. - - - - -Laurie, et al. Expires December 3, 2005 [Page 37] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt deleted file mode 100644 index df702b4..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt +++ /dev/null @@ -1,730 +0,0 @@ - - - - -Network Working Group M. StJohns -Internet-Draft Nominum, Inc. -Expires: February 16, 2006 August 15, 2005 - - - Automated Updates of DNSSEC Trust Anchors - draft-ietf-dnsext-trustupdate-timers-01 - -Status of this Memo - - 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 becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on February 16, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document describes a means for automated, authenticated and - authorized updating of DNSSEC "trust anchors". The method provides - protection against single key compromise of a key in the trust point - key set. Based on the trust established by the presence of a current - anchor, other anchors may be added at the same place in the - hierarchy, and, ultimately, supplant the existing anchor. - - This mechanism, if adopted, will require changes to resolver - management behavior (but not resolver resolution behavior), and the - - - -StJohns Expires February 16, 2006 [Page 1] - -Internet-Draft trustanchor-update August 2005 - - - addition of a single flag bit to the DNSKEY record. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 - 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 - 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 - 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4 - 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 - 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 - 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 - 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 - 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 - 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6 - 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 - 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8 - 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 - 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 - 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9 - 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 - 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 - 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 - Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 - Intellectual Property and Copyright Statements . . . . . . . . 12 - - - - - - - - - - - - - - - - - -StJohns Expires February 16, 2006 [Page 2] - -Internet-Draft trustanchor-update August 2005 - - -1. Introduction - - As part of the reality of fielding DNSSEC (Domain Name System - Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the - community has come to the realization that there will not be one - signed name space, but rather islands of signed name space each - originating from specific points (i.e. 'trust points') in the DNS - tree. Each of those islands will be identified by the trust point - name, and validated by at least one associated public key. For the - purpose of this document we'll call the association of that name and - a particular key a 'trust anchor'. A particular trust point can have - more than one key designated as a trust anchor. - - For a DNSSEC-aware resolver to validate information in a DNSSEC - protected branch of the hierarchy, it must have knowledge of a trust - anchor applicable to that branch. It may also have more than one - trust anchor for any given trust point. Under current rules, a chain - of trust for DNSSEC-protected data that chains its way back to ANY - known trust anchor is considered 'secure'. - - Because of the probable balkanization of the DNSSEC tree due to - signing voids at key locations, a resolver may need to know literally - thousands of trust anchors to perform its duties. (e.g. Consider an - unsigned ".COM".) Requiring the owner of the resolver to manually - manage this many relationships is problematic. It's even more - problematic when considering the eventual requirement for key - replacement/update for a given trust anchor. The mechanism described - herein won't help with the initial configuration of the trust anchors - in the resolvers, but should make trust point key replacement/ - rollover more viable. - - As mentioned above, this document describes a mechanism whereby a - resolver can update the trust anchors for a given trust point, mainly - without human intervention at the resolver. There are some corner - cases discussed (e.g. multiple key compromise) that may require - manual intervention, but they should be few and far between. This - document DOES NOT discuss the general problem of the initial - configuration of trust anchors for the resolver. - -1.1 Compliance Nomenclature - - 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 BCP 14, [RFC2119]. - -1.2 Changes since -00 - - Added the concept of timer triggered resolver queries to refresh the - - - -StJohns Expires February 16, 2006 [Page 3] - -Internet-Draft trustanchor-update August 2005 - - - resolvers view of the trust anchor key RRSet. - - Re-submitted expired draft as -01. Updated DNSSEC RFC References. - -2. Theory of Operation - - The general concept of this mechanism is that existing trust anchors - can be used to authenticate new trust anchors at the same point in - the DNS hierarchy. When a new SEP key is added to a trust point - DNSKEY RRSet, and when that RRSet is validated by an existing trust - anchor, then the new key can be added to the set of trust anchors. - - There are some issues with this approach which need to be mitigated. - For example, a compromise of one of the existing keys could allow an - attacker to add their own 'valid' data. This implies a need for a - method to revoke an existing key regardless of whether or not that - key is compromised. As another example assuming a single key - compromise, an attacker could add a new key and revoke all the other - old keys. - -2.1 Revocation - - Assume two trust anchor keys A and B. Assume that B has been - compromised. Without a specific revocation bit, B could invalidate A - simply by sending out a signed trust point key set which didn't - contain A. To fix this, we add a mechanism which requires knowledge - of the private key of a DNSKEY to revoke that DNSKEY. - - A key is considered revoked when the resolver sees the key in a self- - signed RRSet and the key has the REVOKE bit set to '1'. Once the - resolver sees the REVOKE bit, it MUST NOT use this key as a trust - anchor or for any other purposes except validating the RRSIG over the - DNSKEY RRSet specifically for the purpose of validating the - revocation. Unlike the 'Add' operation below, revocation is - immediate and permanent upon receipt of a valid revocation at the - resolver. - - N.B. A DNSKEY with the REVOKE bit set has a different fingerprint - than one without the bit set. This affects the matching of a DNSKEY - to DS records in the parent, or the fingerprint stored at a resolver - used to configure a trust point. [msj3] - - In the given example, the attacker could revoke B because it has - knowledge of B's private key, but could not revoke A. - -2.2 Add Hold-Down - - Assume two trust point keys A and B. Assume that B has been - - - -StJohns Expires February 16, 2006 [Page 4] - -Internet-Draft trustanchor-update August 2005 - - - compromised. An attacker could generate and add a new trust anchor - key - C (by adding C to the DNSKEY RRSet and signing it with B), and - then invalidate the compromised key. This would result in the both - the attacker and owner being able to sign data in the zone and have - it accepted as valid by resolvers. - - To mitigate, but not completely solve, this problem, we add a hold- - down time to the addition of the trust anchor. When the resolver - sees a new SEP key in a validated trust point DNSKEY RRSet, the - resolver starts an acceptance timer, and remembers all the keys that - validated the RRSet. If the resolver ever sees the DNSKEY RRSet - without the new key but validly signed, it stops the acceptance - process and resets the acceptance timer. If all of the keys which - were originally used to validate this key are revoked prior to the - timer expiring, the resolver stops the acceptance process and resets - the timer. - - Once the timer expires, the new key will be added as a trust anchor - the next time the validated RRSet with the new key is seen at the - resolver. The resolver MUST NOT treat the new key as a trust anchor - until the hold down time expires AND it has retrieved and validated a - DNSKEY RRSet after the hold down time which contains the new key. - - N.B.: Once the resolver has accepted a key as a trust anchor, the key - MUST be considered a valid trust anchor by that resolver until - explictly revoked as described above. - - In the given example, the zone owner can recover from a compromise by - revoking B and adding a new key D and signing the DNSKEY RRSet with - both A and B. - - The reason this does not completely solve the problem has to do with - the distributed nature of DNS. The resolver only knows what it sees. - A determined attacker who holds one compromised key could keep a - single resolver from realizing that key had been compromised by - intercepting 'real' data from the originating zone and substituting - their own (e.g. using the example, signed only by B). This is no - worse than the current situation assuming a compromised key. - -2.3 Remove Hold-down - - A new key which has been seen by the resolver, but hasn't reached - it's add hold-down time, MAY be removed from the DNSKEY RRSet by the - zone owner. If the resolver sees a validated DNSKEY RRSet without - this key, it waits for the remove hold-down time and then, if the key - hasn't reappeared, SHOULD discard any information about the key. - - - - - -StJohns Expires February 16, 2006 [Page 5] - -Internet-Draft trustanchor-update August 2005 - - -2.4 Active Refresh - - A resolver which has been configured for automatic update of keys - from a particular trust point MUST query that trust point (e.g. do a - lookup for the DNSKEY RRSet and related RRSIG records) no less often - than the lesser of 15 days or half the original TTL for the DNSKEY - RRSet or half the RRSIG expiration interval. The expiration interval - is the amount of time from when the RRSIG was last retrieved until - the expiration time in the RRSIG. - - If the query fails, the resolver MUST repeat the query until - satisfied no more often than once an hour and no less often than the - lesser of 1 day or 10% of the original TTL or 10% of the original - expiration interval. - -2.5 Resolver Parameters - -2.5.1 Add Hold-Down Time - - The add hold-down time is 30 days or the expiration time of the TTL - of the first trust point DNSKEY RRSet which contained the key, - whichever is greater. This ensures that at least two validated - DNSKEY RRSets which contain the new key MUST be seen by the resolver - prior to the key's acceptance. - -2.5.2 Remove Hold-Down Time - - The remove hold-down time is 30 days. - -2.5.3 Minimum Trust Anchors per Trust Point - - A compliant resolver MUST be able to manage at least five SEP keys - per trust point. - -3. Changes to DNSKEY RDATA Wire Format - - Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' - flag. If this bit is set to '1', AND the resolver sees an - RRSIG(DNSKEY) signed by the associated key, then the resolver MUST - consider this key permanently invalid for all purposes except for - validing the revocation. - -4. State Table - - The most important thing to understand is the resolver's view of any - key at a trust point. The following state table describes that view - at various points in the key's lifetime. The table is a normative - part of this specification. The initial state of the key is 'Start'. - - - -StJohns Expires February 16, 2006 [Page 6] - -Internet-Draft trustanchor-update August 2005 - - - The resolver's view of the state of the key changes as various events - occur. - - [msj1] This is the state of a trust point key as seen from the - resolver. The column on the left indicates the current state. The - header at the top shows the next state. The intersection of the two - shows the event that will cause the state to transition from the - current state to the next. - - NEXT STATE - -------------------------------------------------- - FROM |Start |AddPend |Valid |Missing|Revoked|Removed| - ---------------------------------------------------------- - Start | |NewKey | | | | | - ---------------------------------------------------------- - AddPend |KeyRem | |AddTime| | | - ---------------------------------------------------------- - Valid | | | |KeyRem |Revbit | | - ---------------------------------------------------------- - Missing | | |KeyPres| |Revbit | | - ---------------------------------------------------------- - Revoked | | | | | |RemTime| - ---------------------------------------------------------- - Removed | | | | | | | - ---------------------------------------------------------- - - -4.1 Events - NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. - That key will become a new trust anchor for the named trust point - after its been present in the RRSet for at least 'add time'. - KeyPres The key has returned to the valid DNSKEY RRSet. - KeyRem The resolver sees a valid DNSKEY RRSet that does not contain - this key. - AddTime The key has been in every valid DNSKEY RRSet seen for at - least the 'add time'. - RemTime A revoked key has been missing from the trust point DNSKEY - RRSet for sufficient time to be removed from the trust set. - RevBit The key has appeared in the trust anchor DNSKEY RRSet with its - "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet - signed by this key. - -4.2 States - Start The key doesn't yet exist as a trust anchor at the resolver. - It may or may not exist at the zone server, but hasn't yet been - seen at the resolver. - - - - - -StJohns Expires February 16, 2006 [Page 7] - -Internet-Draft trustanchor-update August 2005 - - - AddPend The key has been seen at the resolver, has its 'SEP' bit set, - and has been included in a validated DNSKEY RRSet. There is a - hold-down time for the key before it can be used as a trust - anchor. - Valid The key has been seen at the resolver and has been included in - all validated DNSKEY RRSets from the time it was first seen up - through the hold-down time. It is now valid for verifying RRSets - that arrive after the hold down time. Clarification: The DNSKEY - RRSet does not need to be continuously present at the resolver - (e.g. its TTL might expire). If the RRSet is seen, and is - validated (i.e. verifies against an existing trust anchor), this - key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. - Missing This is an abnormal state. The key remains as a valid trust - point key, but was not seen at the resolver in the last validated - DNSKEY RRSet. This is an abnormal state because the zone operator - should be using the REVOKE bit prior to removal. [Discussion - item: Should a missing key be considered revoked after some - period of time?] - Revoked This is the state a key moves to once the resolver sees an - RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains - this key with its REVOKE bit set to '1'. Once in this state, this - key MUST permanently be considered invalid as a trust anchor. - Removed After a fairly long hold-down time, information about this - key may be purged from the resolver. A key in the removed state - MUST NOT be considered a valid trust anchor. - -5. Scenarios - - The suggested model for operation is to have one active key and one - stand-by key at each trust point. The active key will be used to - sign the DNSKEY RRSet. The stand-by key will not normally sign this - RRSet, but the resolver will accept it as a trust anchor if/when it - sees the signature on the trust point DNSKEY RRSet. - - Since the stand-by key is not in active signing use, the associated - private key may (and SHOULD) be provided with additional protections - not normally available to a key that must be used frequently. E.g. - locked in a safe, split among many parties, etc. Notionally, the - stand-by key should be less subject to compromise than an active key, - but that will be dependent on operational concerns not addressed - here. - -5.1 Adding A Trust Anchor - - Assume an existing trust anchor key 'A'. - 1. Generate a new key pair. - - - - - -StJohns Expires February 16, 2006 [Page 8] - -Internet-Draft trustanchor-update August 2005 - - - 2. Create a DNSKEY record from the key pair and set the SEP and Zone - Key bits. - 3. Add the DNSKEY to the RRSet. - 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - - 'A'. - 5. Wait a while. - -5.2 Deleting a Trust Anchor - - Assume existing trust anchors 'A' and 'B' and that you want to revoke - and delete 'A'. - 1. Set the revolcation bit on key 'A'. - 2. Sign the DNSKEY RRSet with both 'A' and 'B'. - 'A' is now revoked. The operator SHOULD include the revoked 'A' in - the RRSet for at least the remove hold-down time, but then may remove - it from the DNSKEY RRSet. - -5.3 Key Roll-Over - - Assume existing keys A and B. 'A' is actively in use (i.e. has been - signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been - in the DNSKEY RRSet and is a valid trust anchor, but wasn't being - used to sign the RRSet.) - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'A'. - 4. Sign the RRSet with 'A' and 'B'. - 'A' is now revoked, 'B' is now the active key, and 'C' will be the - stand-by key once the hold-down expires. The operator SHOULD include - the revoked 'A' in the RRSet for at least the remove hold-down time, - but may then remove it from the DNSKEY RRSet. - -5.4 Active Key Compromised - - This is the same as the mechanism for Key Roll-Over (Section 5.3) - above assuming 'A' is the active key. - -5.5 Stand-by Key Compromised - - Using the same assumptions and naming conventions as Key Roll-Over - (Section 5.3) above: - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'B'. - 4. Sign the RRSet with 'A' and 'B'. - 'B' is now revoked, 'A' remains the active key, and 'C' will be the - stand-by key once the hold-down expires. 'B' SHOULD continue to be - included in the RRSet for the remove hold-down time. - - - -StJohns Expires February 16, 2006 [Page 9] - -Internet-Draft trustanchor-update August 2005 - - -6. Security Considerations - -6.1 Key Ownership vs Acceptance Policy - - The reader should note that, while the zone owner is responsible - creating and distributing keys, it's wholly the decision of the - resolver owner as to whether to accept such keys for the - authentication of the zone information. This implies the decision - update trust anchor keys based on trust for a current trust anchor - key is also the resolver owner's decision. - - The resolver owner (and resolver implementers) MAY choose to permit - or prevent key status updates based on this mechanism for specific - trust points. If they choose to prevent the automated updates, they - will need to establish a mechanism for manual or other out-of-band - updates outside the scope of this document. - -6.2 Multiple Key Compromise - - This scheme permits recovery as long as at least one valid trust - anchor key remains uncompromised. E.g. if there are three keys, you - can recover if two of them are compromised. The zone owner should - determine their own level of comfort with respect to the number of - active valid trust anchors in a zone and should be prepared to - implement recovery procedures once they detect a compromise. A - manual or other out-of-band update of all resolvers will be required - if all trust anchor keys at a trust point are compromised. - -6.3 Dynamic Updates - - Allowing a resolver to update its trust anchor set based in-band key - information is potentially less secure than a manual process. - However, given the nature of the DNS, the number of resolvers that - would require update if a trust anchor key were compromised, and the - lack of a standard management framework for DNS, this approach is no - worse than the existing situation. - -7. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - - -StJohns Expires February 16, 2006 [Page 10] - -Internet-Draft trustanchor-update August 2005 - - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -Editorial Comments - - [msj1] msj: N.B. This table is preliminary and will be revised to - match implementation experience. For example, should there - be a state for "Add hold-down expired, but haven't seen the - new RRSet"? - - [msj2] msj: To be assigned. - - [msj3] msj: For discussion: What's the implementation guidance for - resolvers currently with respect to the non-assigned flag - bits? If they consider the flag bit when doing key matching - at the trust anchor, they won't be able to match. - - -Author's Address - - Michael StJohns - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 - USA - - Phone: +1-301-528-4729 - Email: Mike.StJohns@nominum.com - URI: www.nominum.com - - - - - - - - - - - - - - - - - -StJohns Expires February 16, 2006 [Page 11] - -Internet-Draft trustanchor-update August 2005 - - -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. - - The IETF has been notified of intellectual property rights claimed in - regard to some or all of the specification contained in this - document. For more information consult the online list of claimed - rights. - - -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 (2005). 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. - - - - - -StJohns Expires February 16, 2006 [Page 12] - -Internet-Draft trustanchor-update August 2005 - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -StJohns Expires February 16, 2006 [Page 13] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt deleted file mode 100644 index a59595f..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt +++ /dev/null @@ -1,580 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -UPDATES RFC 2845 Motorola Laboratories -Expires: December 2005 June 2005 - - - HMAC SHA TSIG Algorithm Identifiers - ---- --- ---- --------- ----------- - <draft-ietf-dnsext-tsig-sha-04.txt> - - -Status of This Document - - 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 becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - This draft is intended to be become a Proposed Standard RFC. - Distribution of this document is unlimited. Comments should be sent - to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than a "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Abstract - - Use of the TSIG DNS resource record requires specification of a - cryptographic message authentication code. Currently identifiers - have been specified only for the HMAC-MD5 and GSS TSIG algorithms. - This document standardizes identifiers and implementation - requirements for additional HMAC SHA TSIG algorithms and standardizes - how to specify and handle the truncation of HMAC values. - - -Copyright Notice - - Copyright (C) The Internet Society 2005. All Rights Reserved. - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Copyright Notice...........................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - - 2. Algorithms and Identifiers..............................4 - - 3. Specifying Truncation...................................5 - 3.1 Truncation Specification...............................5 - - 4. TSIG Policy Provisions and Truncation Error.............7 - - 5. IANA Considerations.....................................8 - 6. Security Considerations.................................8 - 6. Copyright and Disclaimer................................8 - - 7. Normative References....................................9 - 8. Informative References..................................9 - - Author's Address..........................................10 - Expiration and File Name..................................10 - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -1. Introduction - - [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to - authenticate DNS queries and responses. This RR contains a domain - name syntax data item which names the authentication algorithm used. - [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for - authentication codes using the HMAC [RFC 2104] algorithm with the MD5 - [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an - identifier for TSIG authentication where the cryptographic operations - are delegated to GSS [RFC 3645]. - - In Section 2, this document specifies additional names for TSIG - authentication algorithms based on US NIST SHA algorithms and HMAC - and specifies the implementation requirements for those algorithms. - - In Section 3, this document specifies the meaning of inequality - between the normal output size of the specified hash function and the - length of MAC (message authentication code) data given in the TSIG - RR. In particular, it specifies that a shorter length field value - specifies truncation and a longer length field is an error. - - In Section 4, policy restrictions and implications related to - truncation and a new error code to indicate truncation shorter than - permitted by policy are described and specified. - - The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as - defined in [RFC 2119]. - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -2. Algorithms and Identifiers - - TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS - queries and responses. They are intended to be efficient symmetric - authentication codes based on a shared secret. (Asymmetric signatures - can be provided using the SIG RR [RFC 2931]. In particular, SIG(0) - can be used for transaction signatures.) Used with a strong hash - function, HMAC [RFC 2104] provides a way to calculate such symmetric - authentication codes. The only specified HMAC based TSIG algorithm - identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. - - The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as - compared with the 128 bits for MD5, and additional hash algorithms in - the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384, - and 512 bits, may be preferred in some cases particularly since - increasingly successful cryptanalytic attacks are being made on the - shorter hashes. Use of TSIG between a DNS resolver and server is by - mutual agreement. That agreement can include the support of - additional algorithms and may specify policies as to which algorithms - and truncations are acceptable subject to the restrication and - guidelines in Section 3 and 4 below. - - The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the - table below for convenience. Implementations which support TSIG MUST - also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig - and the other algorithms listed below. - - Mandatory HMAC-MD5.SIG-ALG.REG.INT - Mandatory hmac-sha1 - Optional hmac-sha224 - Mandatory hmac-sha256 - Optional hamc-sha384 - Optional hmac-sha512 - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -3. Specifying Truncation - - When space is at a premium and the strength of the full length of an - HMAC is not needed, it is reasonable to truncate the HMAC output and - use the truncated value for authentication. HMAC SHA-1 truncated to - 96 bits is an option available in several IETF protocols including - IPSEC and TLS. - - The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the - size of the MAC field in octets. But [RFC 2845] does not specify what - to do if this MAC size differs from the length of the output of HMAC - for a particular hash function. Truncation is indicated by a MAC size - less than the HMAC size as specified below. - - - -3.1 Truncation Specification - - The specification for TSIG handling is changed as follows: - - 1. If "MAC size" field is greater than HMAC output length: - This case MUST NOT be generated and if received MUST cause the - packet to be dropped and RCODE 1 (FORMERR) to be returned. - - 2. If "MAC size" field equals HMAC output length: - Operation is as described in [RFC 2845] with the entire output - HMAC output present. - - 3. "MAC size" field is less than HMAC output length but greater than - that specified in case 4 below: - This is sent when the signer has truncated the HMAC output to - an allowable length, as described in RFC 2104, taking initial - octets and discarding trailing octets. TSIG truncation can only be - to an integral number of octets. On receipt of a packet with - truncation thus indicated, the locally calculated MAC is similarly - truncated and only the truncated values compared for - authentication. The request MAC used when calculating the TSIG MAC - for a reply is the trucated request MAC. - - 4. "MAC size" field is less than the larger of 10 (octets) and half - the length of the hash function in use: - With the exception of certain TSIG error messages described in - RFC 2845 section 3.2 where it is permitted that the MAC size be - zero, this case MUST NOT be generated and if received MUST cause - the packet to be dropped and RCODE 1 (FORMERR) to be returned. The - size limit for this case can also, for the hash functions - mentioned in this document, be stated as less than half the hash - function length for hash functions other than MD5 and less than 10 - octets for MD5. - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - - SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -4. TSIG Policy Provisions and Truncation Error - - Use of TSIG is by mutual agreement between a resolver and server. - Implicit in such "agreement" are policies as to acceptable keys and - algorithms and, with the extensions in this doucment, truncations. In - particular note the following: - - Such policies MAY require the rejection of TSIGs even though they - use an algorithm for which implementation is mandatory. - - When a policy calls for the acceptance of a TSIG with a particular - algorithm and a particular non-zero amount of trunction it SHOULD - also permit the use of that algorithm with lesser truncation (a - longer MAC) up to the full HMAC output. - - Regardless of a lower acceptable truncated MAC length specified by - policy, a reply SHOULD be sent with a MAC at least as long as that in - the corresponding request unless the request specified a MAC length - longer than the HMAC output. - - Implementations permitting policies with multiple acceptable - algorithms and/or truncations SHOULD permit this list to be ordered - by presumed strength and SHOULD allow different truncations for the - same algorithm to be treatred as spearate entities in this list. When - so implemented, policies SHOULD accept a presumed stronger algorithm - and truncation than the minimum strength required by the policy. - - If a TSIG is received with truncation which is permitted under - Section 3 above but the MAC is too short for the policy in force, an - RCODE of TBA [22 suggested](BADTRUNC) MUST be returned. - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -5. IANA Considerations - - This document, on approval for publication as a standards track RFC, - (1) registers the new TSIG algorithm identifiers listed in Section 2 - with IANA and (2) Section 4 allocates the BADTRUNC RCODE TBA [22 - suggested]. - - - - -6. Security Considerations - - For all of the message authentication code algorithms listed herein, - those producing longer values are believed to be stronger; however, - while there have been some arguments that mild truncation can - strengthen a MAC by reducing the information available to an - attacker, excessive truncation clearly weakens authentication by - reducing the number of bits an attacker has to try to brute force - [RFC 2104]. - - Significant progress has been made recently in cryptanalysis of hash - function of the type used herein, all of which ultimately derive from - the design of MD4. While the results so far should not effect HMAC, - the stronger SHA-1 and SHA-256 algorithms are being made mandatory - due to caution. - - See the Security Considerations section of [RFC 2845]. See also the - Security Considerations section of [RFC 2104] from which the limits - on truncation in this RFC were taken. - - - -6. Copyright and Disclaimer - - Copyright (C) The Internet Society (2005). This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -7. Normative References - - [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US - Federal Information Processing Standard, with Change Notice 1, - February 2004. - - [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC - 1321, April 1992. - - [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February 1997. - - [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - - -8. Informative References. - - [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction - Signatures ( SIG(0)s )", RFC 2931, September 2000. - - [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm - 1 (SHA1)", RFC 3174, September 2001. - - [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, - J., and R. Hall, "Generic Security Service Algorithm for Secret Key - Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October - 2003. - - [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224", - September 2004, - - [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms - (SHA)", work in progress. - - - - - - - - - - - - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 (w) - - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in December 2005. - - Its file name is draft-ietf-dnsext-tsig-sha-04.txt - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 10] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt deleted file mode 100644 index fad88ae..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt +++ /dev/null @@ -1,956 +0,0 @@ -DNSEXT Working Group E. Lewis -INTERNET DRAFT NeuStar -Expiration Date: January 6, 2006 July 6, 2005 -Updates RFC 1034, RFC 2672 - - The Role of Wildcards - in the Domain Name System - draft-ietf-dnsext-wcard-clarify-08.txt - -Status of this Memo - - 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 - becomes aware will be disclosed, in accordance with Section 6 of - BCP 79. - - 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 6, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This is an update to the wildcard definition of RFC 1034. The - interaction with wildcards and CNAME is changed, an error - condition removed, and the words defining some concepts central - to wildcards are changed. The overall goal is not to change - wildcards, but to refine the definition of RFC 1034. - -Table of Contents - -1. Introduction -1.1 Motivation -1.2 The Original Definition -1.3 Roadmap to This Document -1.3.1 New Terms -1.3.2 Changed Text -1.3.3 Considerations with Special Types -1.4 Standards Terminology -2. Wildcard Syntax -2.1 Identifying a Wildcard -2.1.1 Wild Card Domain Name and Asterisk Label -2.1.2 Asterisks and Other Characters -2.1.3 Non-terminal Wild Card Domain Names -2.2 Existence Rules -2.2.1 An Example -2.2.2 Empty Non-terminals -2.2.3 Yet Another Definition of Existence -2.3 When is a Wild Card Domain Name Not Special -3. Impact of a Wild Card Domain Name On a Response -3.1 Step 2 -3.2 Step 3 -3.3 Part 'c' -3.3.1 Closest Encloser and the Source of Synthesis -3.3.2 Closest Encloser and Source of Synthesis Examples -3.3.3 Type Matching -4. Considerations with Special Types -4.1 SOA RRSet at a Wild Card Domain Name -4.2 NS RRSet at a Wild Card Domain Name -4.2.1 Discarded Notions -4.3 CNAME RRSet at a Wild Card Domain Name -4.4 DNAME RRSet at a Wild Card Domain Name -4.5 SRV RRSet at a Wild Card Domain Name -4.6 DS RRSet at a Wild Card Domain Name -4.7 NSEC RRSet at a Wild Card Domain Name -4.8 RRSIG at a Wild Card Domain Name -4.9 Empty Non-terminal Wild Card Domain Name -5. Security Considerations -6. IANA Considerations -7. References -8. Editor -9. Others Contributing to the Document -10. Trailing Boilerplate - -1. Introduction - - In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the - synthesis of answers from special resource records called - wildcards. The definition in RFC 1034 is incomplete and has - proven to be confusing. This document describes the wildcard - synthesis by adding to the discussion and making limited - modifications. Modifications are made to close inconsistencies - that have led to interoperability issues. This description - does not expand the service intended by the original definition. - - Staying within the spirit and style of the original documents, - this document avoids specifying rules for DNS implementations - regarding wildcards. The intention is to only describe what is - needed for interoperability, not restrict implementation choices. - In addition, consideration is given to minimize any backwards - compatibility issues with implementations that comply with RFC - 1034's definition. - - This document is focused on the concept of wildcards as defined - in RFC 1034. Nothing is implied regarding alternative means of - synthesizing resource record sets, nor are alternatives discussed. - -1.1 Motivation - - Many DNS implementations diverge, in different ways, from the - original definition of wildcards. Although there is clearly a - need to clarify the original documents in light of this alone, - the impetus for this document lay in the engineering of the DNS - security extensions [RFC4033]. With an unclear definition of - wildcards the design of authenticated denial became entangled. - - This document is intended to limit its changes, documenting only - those based on implementation experience, and to remain as close - to the original document as possible. To reinforce that this - document is meant to clarify and adjust and not redefine wildcards, - relevant sections of RFC 1034 are repeated verbatim to facilitate - comparison of the old and new text. - -1.2 The Original Definition - - The defintion of the wildcard concept is comprised by the - documentation of the algorithm by which a name server prepares - a response (in RFC 1034's section 4.3.2) and the way in which - a resource record (set) is identified as being a source of - synthetic data (section 4.3.3). - - This is the definition of the term "wildcard" as it appears in - RFC 1034, section 4.3.3. - -# In the previous algorithm, special treatment was given to RRs with -# owner names starting with the label "*". Such RRs are called -# wildcards. Wildcard RRs can be thought of as instructions for -# synthesizing RRs. When the appropriate conditions are met, the name -# server creates RRs with an owner name equal to the query name and -# contents taken from the wildcard RRs. - - This passage follows the algorithm in which the term wildcard - is first used. In this definition, wildcard refers to resource - records. In other usage, wildcard has referred to domain names, - and it has been used to describe the operational practice of - relying on wildcards to generate answers. It is clear from this - that there is a need to define clear and unambiguous terminology - in the process of discussing wildcards. - - The mention of the use of wildcards in the preparation of a - response is contained in step 3c of RFC 1034's section 4.3.2 - entitled "Algorithm." Note that "wildcard" does not appear in - the algorithm, instead references are made to the "*" label. - The portion of the algorithm relating to wildcards is - deconstructed in detail in section 3 of this document, this is - the beginning of the relevant portion of the "Algorithm." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if [...] -# the "*" label exists. - - The scope of this document is the RFC 1034 definition of - wildcards and the implications of updates to those documents, - such as DNSSEC. Alternate schemes for synthesizing answers are - not considered. (Note that there is no reference listed. No - document is known to describe any alternate schemes, although - there has been some mention of them in mailing lists.) - -1.3 Roadmap to This Document - - This document accomplishes these three items. - o Defines new terms - o Makes minor changes to avoid conflicting concepts - o Describes the actions of certain resource records as wildcards - -1.3.1 New Terms - - To help in discussing what resource records are wildcards, two - terms will be defined - "asterisk label" and "wild card domain - name". These are defined in section 2.1.1. - - To assist in clarifying the role of wildcards in the name server - algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest - encloser" are defined. These definitions are in section 3.3.2. - "Label match" is defined in section 3.2. - - The new terms are used to make discussions of wildcards clearer. - Terminology doesn't directly have an impact on implementations. - -1.3.2 Changed Text - - The definition of "existence" is changed superficially. This - change will not be apparent to implementations; it is needed to - make descriptions more precise. The change appears in section - 2.2.3. - - RFC 1034, section 4.3.3., seems to prohibit having two asterisk - labels in a wildcard owner name. With this document the - restriction is removed entirely. This change and its implications - are in section 2.1.3. - - The actions when a source of synthesis owns a CNAME RR are - changed to mirror the actions if an exact match name owns a - CNAME RR. This is an addition to the words in RFC 1034, - section 4.3.2, step 3, part c. The discussion of this is in - section 3.3.3. - - Only the latter change represents an impact to implementations. - The definition of existence is not a protocol impact. The change - to the restriction on names is unlikely to have an impact, as - RFC 1034 contained no specification on when and how to enforce the - restriction. - -1.3.3 Considerations with Special Types - - This document describes semantics of wildcard RRSets for - "interesting" types as well as empty non-terminal wildcards. - Understanding these situations in the context of wildcards has - been clouded because these types incur special processing if - they are the result of an exact match. This discussion is in - section 4. - - These discussions do not have an implementation impact, they cover - existing knowledge of the types, but to a greater level of detail. - -1.4 Standards Terminology - - This document does not use terms as defined in "Key words for use - in RFCs to Indicate Requirement Levels." [RFC2119] - - Quotations of RFC 1034 are denoted by a '#' in the leftmost - column. References to section "4.3.2" are assumed to refer - to RFC 1034's section 4.3.2, simply titled "Algorithm." - -2. Wildcard Syntax - - The syntax of a wildcard is the same as any other DNS resource - record, across all classes and types. The only significant - feature is the owner name. - - Because wildcards are encoded as resource records with special - names, they are included in zone transfers and incremental zone - transfers[RFC1995] just as non-wildcard resource records are. - This feature has been underappreciated until discussions on - alternative approaches to wildcards appeared on mailing lists. - -2.1 Identifying a Wildcard - - To provide a more accurate description of wildcards, the - definition has to start with a discussion of the domain names - that appear as owners. Two new terms are needed, "Asterisk - Label" and "Wild Card Domain Name." - -2.1.1 Wild Card Domain Name and Asterisk Label - - A "wild card domain name" is defined by having its initial - (i.e., left-most or least significant) label be, in binary format: - - 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) - - The first octet is the normal label type and length for a 1 octet - long label, the second octet is the ASCII representation [RFC20] - for the '*' character. - - A descriptive name of a label equaling that value is an "asterisk - label." - - RFC 1034's definition of wildcard would be "a resource record - owned by a wild card domain name." - -2.1.2 Asterisks and Other Characters - - No label values other than that in section 2.1.1 are asterisk - labels, hence names beginning with other labels are never wild - card domain names. Labels such as 'the*' and '**' are not - asterisk labels so these labels do not start wild card domain - names. - -2.1.3 Non-terminal Wild Card Domain Names - - In section 4.3.3, the following is stated: - -# .......................... The owner name of the wildcard RRs is of -# the form "*.<anydomain>", where <anydomain> is any domain name. -# <anydomain> should not contain other * labels...................... - - The restriction is now removed. The original documentation of it - is incomplete and the restriction does not serve any purpose given - years of operational experience. - - There are three possible reasons for putting the restriction in - place, but none of the three has held up over time. One is - that the restriction meant that there would never be subdomains - of wild card domain names, but the restriciton as stated still - permits "example.*.example." for instance. Another is that - wild card domain names are not intended to be empty non-terminals, - but this situation does not disrupt the algorithm in 4.3.2. - Finally, "nested" wild card domain names are not ambiguous once - the concept of the closest encloser had been documented. - - A wild card domain name can have subdomains. There is no need - to inspect the subdomains to see if there is another asterisk - label in any subdomain. - - A wild card domain name can be an empty non-terminal. (See the - upcoming sections on empty non-terminals.) In this case, any - lookup encountering it will terminate as would any empty - non-terminal match. - -2.2 Existence Rules - - The notion that a domain name 'exists' is mentioned in the - definition of wildcards. In section 4.3.3 of RFC 1034: - -# Wildcard RRs do not apply: -# -... -# - When the query name or a name between the wildcard domain and -# the query name is know[n] to exist. For example, if a wildcard - - "Existence" is therefore an important concept in the understanding - of wildcards. Unfortunately, the definition of what exists, in RFC - 1034, is unlcear. So, in sections 2.2.2. and 2.2.3, another look is - taken at the definition of existence. - -2.2.1 An Example - - To illustrate what is meant by existence consider this complete - zone: - - $ORIGIN example. - example. 3600 IN SOA <SOA RDATA> - example. 3600 NS ns.example.com. - example. 3600 NS ns.example.net. - *.example. 3600 TXT "this is a wild card" - *.example. 3600 MX 10 host1.example. - sub.*.example. 3600 TXT "this is not a wild card" - host1.example. 3600 A 192.0.4.1 - _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> - _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> - subdel.example. 3600 NS ns.example.com. - subdel.example. 3600 NS ns.example.net. - - A look at the domain names in a tree structure is helpful: - - | - -------------example------------ - / / \ \ - / / \ \ - / / \ \ - * host1 host2 subdel - | | | - | | | - sub _tcp _tcp - | | - | | - _ssh _ssh - - The following responses would be synthesized from one of the - wildcards in the zone: - - QNAME=host3.example. QTYPE=MX, QCLASS=IN - the answer will be a "host3.example. IN MX ..." - - QNAME=host3.example. QTYPE=A, QCLASS=IN - the answer will reflect "no error, but no data" - because there is no A RR set at '*.example.' - - QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN - the answer will be "foo.bar.example. IN TXT ..." - because bar.example. does not exist, but the wildcard - does. - - The following responses would not be synthesized from any of the - wildcards in the zone: - - QNAME=host1.example., QTYPE=MX, QCLASS=IN - because host1.example. exists - - QNAME=sub.*.example., QTYPE=MX, QCLASS=IN - because sub.*.example. exists - - QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN - because _tcp.host1.example. exists (without data) - - QNAME=host.subdel.example., QTYPE=A, QCLASS=IN - because subdel.example. exists (and is a zone cut) - - QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN - because *.example. exists - - The final example highlights one common misconception about - wildcards. A wildcard "blocks itself" in the sense that a - wildcard does not match its own subdomains. I.e. "*.example." - does not match all names in the "example." zone, it fails to - match the names below "*.example." To cover names under - "*.example.", another wild card domain name is needed - - "*.*.example." - which covers all but it's own subdomains. - -2.2.2 Empty Non-terminals - - Empty non-terminals [RFC2136, Section 7.16] are domain names - that own no resource records but have subdomains that do. In - section 2.2.1, "_tcp.host1.example." is an example of a empty - non-terminal name. Empty non-terminals are introduced by this - text in section 3.1 of RFC 1034: - -# The domain name space is a tree structure. Each node and leaf on -# the tree corresponds to a resource set (which may be empty). The -# domain system makes no distinctions between the uses of the -# interior nodes and leaves, and this memo uses the term "node" to -# refer to both. - - The parenthesized "which may be empty" specifies that empty non- - terminals are explicitly recognized, and that empty non-terminals - "exist." - - Pedantically reading the above paragraph can lead to an - interpretation that all possible domains exist - up to the - suggested limit of 255 octets for a domain name [RFC1035]. - For example, www.example. may have an A RR, and as far as is - practically concerned, is a leaf of the domain tree. But the - definition can be taken to mean that sub.www.example. also - exists, albeit with no data. By extension, all possible domains - exist, from the root on down. - - As RFC 1034 also defines "an authoritative name error indicating - that the name does not exist" in section 4.3.1, so this apparently - is not the intent of the original definition, justifying the - need for an updated definition in the next section. - -2.2.3 Yet Another Definition of Existence - - RFC1034's wording is fixed by the following paragraph: - - The domain name space is a tree structure. Nodes in the tree - either own at least one RRSet and/or have descendants that - collectively own at least one RRSet. A node may exist with no - RRSets only if it has descendents that do, this node is an empty - non-terminal. - - A node with no descendants is a leaf node. Empty leaf nodes do - not exist. - - Note that at a zone boundary, the domain name owns data, - including the NS RR set. In the delegating zone, the NS RR - set is not authoritative, but that is of no consequence here. - The domain name owns data, therefore, it exists. - -2.3 When is a Wild Card Domain Name Not Special - - When a wild card domain name appears in a message's query section, - no special processing occurs. An asterisk label in a query name - only matches a single, corresponding asterisk label in the - existing zone tree when the 4.3.2 algorithm is being followed. - - When a wild card domain name appears in the resource data of a - record, no special processing occurs. An asterisk label in that - context literally means just an asterisk. - -3. Impact of a Wild Card Domain Name On a Response - - RFC 1034's description of how wildcards impact response - generation is in its section 4.3.2. That passage contains the - algorithm followed by a server in constructing a response. - Within that algorithm, step 3, part 'c' defines the behavior of - the wildcard. - - The algorithm in section 4.3.2. is not intended to be pseudo-code, - i.e., its steps are not intended to be followed in strict order. - The "algorithm" is a suggested means of implementing the - requirements. As such, in step 3, parts a, b, and c, do not have - to be implemented in that order, provided that the result of the - implemented code is compliant with the protocol's specification. - -3.1 Step 2 - - Step 2 of the section 4.3.2 reads: - -# 2. Search the available zones for the zone which is the nearest -# ancestor to QNAME. If such a zone is found, go to step 3, -# otherwise step 4. - - In this step, the most appropriate zone for the response is - chosen. The significance of this step is that it means all of - step 3 is being performed within one zone. This has significance - when considering whether or not an SOA RR can be ever be used for - synthesis. - -3.2 Step 3 - - Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. - But the beginning of the step is important and needs explanation. - -# 3. Start matching down, label by label, in the zone. The -# matching process can terminate several ways: - - The word 'matching' refers to label matching. The concept - is based in the view of the zone as the tree of existing names. - The query name is considered to be an ordered sequence of - labels - as if the name were a path from the root to the owner - of the desired data. (Which it is - 3rd paragraph of RFC 1034, - section 3.1.) - - The process of label matching a query name ends in exactly one of - three choices, the parts 'a', 'b', and 'c'. Either the name is - found, the name is below a cut point, or the name is not found. - - Once one of the parts is chosen, the other parts are not - considered. (E.g., do not execute part 'c' and then change - the execution path to finish in part 'b'.) The process of label - matching is also done independent of the query type (QTYPE). - - Parts 'a' and 'b' are not an issue for this clarification as they - do not relate to record synthesis. Part 'a' is an exact match - that results in an answer, part 'b' is a referral. - -3.3 Part 'c' - - The context of part 'c' is that the process of label matching the - labels of the query name has resulted in a situation in which - there is no corresponding label in the tree. It is as if the - lookup has "fallen off the tree." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if [...] -# the "*" label exists. - - To help describe the process of looking 'to see if [...] the "*" - label exists' a term has been coined to describe the last domain - (node) matched. The term is "closest encloser." - -3.3.1 Closest Encloser and the Source of Synthesis - - The closest encloser is the node in the zone's tree of existing - domain names that has the most labels matching the query name - (consecutively, counting from the root label downward). Each match - is a "label match" and the order of the labels is the same. - - The closest encloser is, by definition, an existing name in the - zone. The closest encloser might be an empty non-terminal or even - be a wild card domain name itself. In no circumstances is the - closest encloser to be used to synthesize records for the current - query. - - The source of synthesis is defined in the context of a query - process as that wild card domain name immediately descending - from the closest encloser, provided that this wild card domain - name exists. "Immediately descending" means that the source - of synthesis has a name of the form: - <asterisk label>.<closest encloser>. - A source of synthesis does not guarantee having a RRSet to use - for synthesis. The source of synthesis could be an empty - non-terminal. - - If the source of synthesis does not exist (not on the domain - tree), there will be no wildcard synthesis. There is no search - for an alternate. - - The important concept is that for any given lookup process, there - is at most one place at which wildcard synthetic records can be - obtained. If the source of synthesis does not exist, the lookup - terminates, the lookup does not look for other wildcard records. - -3.3.2 Closest Encloser and Source of Synthesis Examples - - To illustrate, using the example zone in section 2.2.1 of this - document, the following chart shows QNAMEs and the closest - enclosers. - - QNAME Closest Encloser Source of Synthesis - host3.example. example. *.example. - _telnet._tcp.host1.example. _tcp.host1.example. no source - _telnet._tcp.host2.example. host2.example. no source - _telnet._tcp.host3.example. example. *.example. - _chat._udp.host3.example. example. *.example. - foobar.*.example. *.example. no source - -3.3.3 Type Matching - - RFC 1034 concludes part 'c' with this: - -# If the "*" label does not exist, check whether the name -# we are looking for is the original QNAME in the query -# or a name we have followed due to a CNAME. If the name -# is original, set an authoritative name error in the -# response and exit. Otherwise just exit. -# -# If the "*" label does exist, match RRs at that node -# against QTYPE. If any match, copy them into the answer -# section, but set the owner of the RR to be QNAME, and -# not the node with the "*" label. Go to step 6. - - The final paragraph covers the role of the QTYPE in the lookup - process. - - Based on implementation feedback and similarities between step - 'a' and step 'c' a change to this passage has been made. - - The change is to add the following text to step 'c' prior to the - instructions to "go to step 6": - - If the data at the source of synthesis is a CNAME, and - QTYPE doesn't match CNAME, copy the CNAME RR into the - answer section of the response changing the owner name - to the QNAME, change QNAME to the canonical name in the - CNAME RR, and go back to step 1. - - This is essentially the same text in step a covering the - processing of CNAME RRSets. - -4. Considerations with Special Types - - Sections 2 and 3 of this document discuss wildcard synthesis - with respect to names in the domain tree and ignore the impact - of types. In this section, the implication of wildcards of - specific types are discussed. The types covered are those - that have proven to be the most difficult to understand. The - types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and - "none," i.e., empty non-terminal wild card domain names. - -4.1 SOA RRSet at a Wild Card Domain Name - - A wild card domain name owning an SOA RRSet means that the - domain is at the root of the zone (apex). The domain can not - be a source of synthesis because that is, by definition, a - descendent node (of the closest encloser) and a zone apex is - at the top of the zone. - - Although a wild card domain name owning an SOA RRSet can never - be a source of synthesis, there is no reason to forbid the - ownership of an SOA RRSet. - - E.g., given this zone: - $ORIGIN *.example. - @ 3600 IN SOA <SOA RDATA> - 3600 NS ns1.example.com. - 3600 NS ns1.example.net. - www 3600 TXT "the www txt record" - - A query for www.*.example.'s TXT record would still find the - "the www txt record" answer. The reason is that the asterisk - label only becomes significant when section's 4.3.2, step 3 - part 'c' in in effect. - - Of course, there would need to be a delegation in the parent - zone, "example." for this to work too. This is covered in the - next section. - -4.2 NS RRSet at a Wild Card Domain Name - - With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now - in place, the semantics of a wild card domain name owning an - NS RRSet has come to be poorly defined. The dilemma relates to - a conflict between the rules for synthesis in part 'c' and the - fact that the resulting synthesis generates a record for which - the zone is not authoritative. In a DNSSEC signed zone, the - mechanics of signature management (generation and inclusion - in a message) become unclear. - - After some lengthy discussions, there has been no clear "best - answer" on how to document the semantics of such a situation. - Barring such records from the DNS would require definition of - rules for that, as well as introducing a restriction on records - that were once legal. Allowing such records and amending the - process of signature management would entail complicating the - DNSSEC definition. - - There is one more ingredient to the discussion, that being the - utility of a wild card domain name owned NS RRSet. Although - there are cases of this use, it is an operational rarity. - Expending effort to close this topic has proven to be an - exercise in diminishing returns. - - In summary, there is no definition given for wild card domain - names owning an NS RRSet. The semantics are left undefined until - there is a clear need to have a set defined, and until there is - a clear direction to proceed. Operationally, inclusion of wild - card NS RRSets in a zone is discouraged, but not barred. - -4.2.1 Discarded Notions - - Prior to DNSSEC, a wild card domain name owning a NS RRSet - appeared to be workable, and there are some instances in which - it is found in deployments using implementations that support - this. Continuing to allow this in the specificaion is not - tenable with DNSSEC. The reason is that the synthesis of the - NS RRSet is being done in a zone that has delegated away the - responsibility for the name. This "unauthorized" synthesis is - not a problem for the base DNS protocol, but DNSSEC, in affirming - the authorization model for DNS exposes the problem. - - Outright banning of wildcards of type NS is also untenable as - the DNS protocol does not define how to handle "illegal" data. - Implementations may choose not to load a zone, but there is no - protocol definition. The lack of the definition is complicated - by having to cover dynamic update [RFC 2136], zone transfers, - as well as loading at the master server. The case of a client - (resolver, cacheing server) getting a wildcard of type NS in - a reply would also have to be considered. - - Given the daunting challenge of a complete definition of how to - ban such records, dealing with existing implementations that - permit the records today is a further complication. There are - uses of wild card domain name owning NS RRSets. - - One compromise proposed would have redefined wildcards of type - NS to not be used in synthesis, this compromise fell apart - because it would have required significant edits to the DNSSEC - signing and validation work. (Again, DNSSEC catches - unauthorized data.) - - With no clear consensus forming on the solution to this dilemma, - and the realization that wildcards of type NS are a rarity in - operations, the best course of action is to leave this open-ended - until "it matters." - -4.3 CNAME RRSet at a Wild Card Domain Name - - The issue of a CNAME RRSet owned by a wild card domain name has - prompted a suggested change to the last paragraph of step 3c of - the algorithm in 4.3.2. The changed text appears in section - 3.3.3 of this document. - -4.4 DNAME RRSet at a Wild Card Domain Name - - Ownership of a DNAME [RFC2672] RRSet by a wild card domain name - represents a threat to the coherency of the DNS and is to be - avoided or outright rejected. Such a DNAME RRSet represents - non-deterministic synthesis of rules fed to different caches. - As caches are fed the different rules (in an unpredictable - manner) the caches will cease to be coherent. ("As caches - are fed" refers to the storage in a cache of records obtained - in responses by recursive or iterative servers.) - - For example, assume one cache, responding to a recursive - request, obtains the record: - "a.b.example. DNAME foo.bar.example.net." - and another cache obtains: - "b.example. DNAME foo.bar.example.net." - both generated from the record: - "*.example. DNAME foo.bar.example.net." - by an authoritative server. - - The DNAME specification is not clear on whether DNAME records - in a cache are used to rewrite queries. In some interpretations, - the rewrite occurs, in some, it is not. Allowing for the - occurrence of rewriting, queries for "sub.a.b.example. A" may - be rewritten as "sub.foo.bar.tld. A" by the former caching - server and may be rewritten as "sub.a.foo.bar.tld. A" by the - latter. Coherency is lost, an operational nightmare ensues. - - Another justification for banning or avoiding wildcard DNAME - records is the observation that such a record could synthesize - a DNAME owned by "sub.foo.bar.example." and "foo.bar.example." - There is a restriction in the DNAME definition that no domain - exist below a DNAME-owning domain, hence, the wildcard DNAME - is not to be permitted. - -4.5 SRV RRSet at a Wild Card Domain Name - - The definition of the SRV RRset is RFC 2782 [RFC2782]. In the - definition of the record, there is some confusion over the term - "Name." The definition reads as follows: - -# The format of the SRV RR -... -# _Service._Proto.Name TTL Class SRV Priority Weight Port Target -... -# Name -# The domain this RR refers to. The SRV RR is unique in that the -# name one searches for is not this name; the example near the end -# shows this clearly. - - Do not confuse the definition "Name" with the owner name. I.e., - once removing the _Service and _Proto labels from the owner name - of the SRV RRSet, what remains could be a wild card domain name - but this is immaterial to the SRV RRSet. - - E.g., If an SRV record is: - _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. - - *.example is a wild card domain name and although it it the Name - of the SRV RR, it is not the owner (domain name). The owner - domain name is "_foo._udp.*.example." which is not a wild card - domain name. - - The confusion is likely based on the mixture of the specification - of the SRV RR and the description of a "use case." - -4.6 DS RRSet at a Wild Card Domain Name - - A DS RRSet owned by a wild card domain name is meaningless and - harmless. This statement is made in the context that an NS RRSet - at a wild card domain name is undefined. At a non-delegation - point, a DS RRSet has no value (no corresponding DNSKEY RRSet - will be used in DNSSEC validation). If there is a synthesized - DS RRSet, it alone will not be very useful as it exists in the - context of a delegation point. - -4.7 NSEC RRSet at a Wild Card Domain Name - - Wild card domain names in DNSSEC signed zones will have an NSEC - RRSet. Synthesis of these records will only occur when the - query exactly matches the record. Synthesized NSEC RR's will not - be harmful as they will never be used in negative caching or to - generate a negative response. - -4.8 RRSIG at a Wild Card Domain Name - - RRSIG records will be present at a wild card domain name in a - signed zone, and will be synthesized along with data sought in a - query. The fact that the owner name is synthesized is not a - problem as the label count in the RRSIG will instruct the - verifying code to ignore it. - -4.9 Empty Non-terminal Wild Card Domain Name - - If a source of synthesis is an empty non-terminal, then the - response will be one of no error in the return code and no RRSet - in the answer section. - -5. Security Considerations - - This document is refining the specifications to make it more - likely that security can be added to DNS. No functional - additions are being made, just refining what is considered - proper to allow the DNS, security of the DNS, and extending - the DNS to be more predictable. - -6. IANA Considerations - - None. - -7. References - - Normative References - - [RFC20] ASCII Format for Network Interchange, V.G. Cerf, - Oct-16-1969 - - [RFC1034] Domain Names - Concepts and Facilities, - P.V. Mockapetris, Nov-01-1987 - - [RFC1035] Domain Names - Implementation and Specification, P.V - Mockapetris, Nov-01-1987 - - [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996 - - [RFC2119] Key Words for Use in RFCs to Indicate Requirement - Levels, S Bradner, March 1997 - - [RFC2181] Clarifications to the DNS Specification, R. Elz and - R. Bush, July 1997 - - [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), - M. Andrews, March 1998 - - [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, - August 1999. - - [RFC2782] A DNS RR for specifying the location of services (DNS - SRV), A. Gulbrandsen, et.al., February 2000 - - [RFC4033] DNS Security Introduction and Requirements, R. Arends, - et.al., March 2005 - - [RFC4034] Resource Records for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - [RFC4035] Protocol Modifications for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, - August 1999 - - Informative References - - [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, - April 1997 - -8. Editor - - Name: Edward Lewis - Affiliation: NeuStar - Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US - Phone: +1-571-434-5468 - Email: ed.lewis@neustar.biz - - Comments on this document can be sent to the editor or the mailing - list for the DNSEXT WG, namedroppers@ops.ietf.org. - -9. Others Contributing to the Document - - This document represents the work of a large working group. The - editor merely recorded the collective wisdom of the working group. - -10. Trailing Boilerplate - - Copyright (C) The Internet Society (2005). - - 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. - -Intellectual Property - - 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - -Expiration - - This document expires on or about January 6, 2006. diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt deleted file mode 100644 index a56969e..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt +++ /dev/null @@ -1,1176 +0,0 @@ - - - -DNS Operations M. Larson -Internet-Draft P. Barber -Expires: January 18, 2006 VeriSign - July 17, 2005 - - - Observed DNS Resolution Misbehavior - draft-ietf-dnsop-bad-dns-res-04 - -Status of this Memo - - 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 becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - 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 18, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This memo describes DNS iterative resolver behavior that results in a - significant query volume sent to the root and top-level domain (TLD) - name servers. We offer implementation advice to iterative resolver - developers to alleviate these unnecessary queries. The - recommendations made in this document are a direct byproduct of - observation and analysis of abnormal query traffic patterns seen at - two of the thirteen root name servers and all thirteen com/net TLD - name servers. - - - -Larson & Barber Expires January 18, 2006 [Page 1] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 A note about terminology in this memo . . . . . . . . . . 3 - 2. Observed iterative resolver misbehavior . . . . . . . . . . 5 - 2.1 Aggressive requerying for delegation information . . . . . 5 - 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . 6 - 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 7 - 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7 - 2.3 Inability to follow multiple levels of indirection . . . . 8 - 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9 - 2.4 Aggressive retransmission when fetching glue . . . . . . . 9 - 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 10 - 2.5 Aggressive retransmission behind firewalls . . . . . . . . 10 - 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11 - 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 11 - 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12 - 2.7 Name server records with zero TTL . . . . . . . . . . . . 12 - 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13 - 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 13 - 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 14 - 2.9 Queries for domain names resembling IPv4 addresses . . . . 14 - 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 14 - 2.10 Misdirected recursive queries . . . . . . . . . . . . . 15 - 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 15 - 2.11 Suboptimal name server selection algorithm . . . . . . . 15 - 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . 16 - 3. IANA considerations . . . . . . . . . . . . . . . . . . . . 17 - 4. Security considerations . . . . . . . . . . . . . . . . . . 18 - 5. Internationalization considerations . . . . . . . . . . . . 19 - 6. Informative References . . . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 - Intellectual Property and Copyright Statements . . . . . . . 21 - - - - - - - - - - - - - - -Larson & Barber Expires January 18, 2006 [Page 2] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - -1. Introduction - - Observation of query traffic received by two root name servers and - the thirteen com/net TLD name servers has revealed that a large - proportion of the total traffic often consists of "requeries". A - requery is the same question (<QNAME, QTYPE, QCLASS>) asked - repeatedly at an unexpectedly high rate. We have observed requeries - from both a single IP address and multiple IP addresses (i.e., the - same query received simultaneously from multiple IP addresses). - - By analyzing requery events we have found that the cause of the - duplicate traffic is almost always a deficient iterative resolver, - stub resolver or application implementation combined with an - operational anomaly. The implementation deficiencies we have - identified to date include well-intentioned recovery attempts gone - awry, insufficient caching of failures, early abort when multiple - levels of indirection must be followed, and aggressive retry by stub - resolvers or applications. Anomalies that we have seen trigger - requery events include lame delegations, unusual glue records, and - anything that makes all authoritative name servers for a zone - unreachable (DoS attacks, crashes, maintenance, routing failures, - congestion, etc.). - - In the following sections, we provide a detailed explanation of the - observed behavior and recommend changes that will reduce the requery - rate. None of the changes recommended affects the core DNS protocol - specification; instead, this document consists of guidelines to - implementors of iterative resolvers. - -1.1 A note about terminology in this memo - - To recast an old saying about standards, the nice thing about DNS - terms is that there are so many of them to choose from. Writing or - talking about DNS can be difficult and cause confusion resulting from - a lack of agreed-upon terms for its various components. Further - complicating matters are implementations that combine multiple roles - into one piece of software, which makes naming the result - problematic. An example is the entity that accepts recursive - queries, issues iterative queries as necessary to resolve the initial - recursive query, caches responses it receives, and which is also able - to answer questions about certain zones authoritatively. This entity - is an iterative resolver combined with an authoritative name server - and is often called a "recursive name server" or a "caching name - server". - - This memo is concerned principally with the behavior of iterative - resolvers, which are typically found as part of a recursive name - server. This memo uses the more precise term "iterative resolver", - - - -Larson & Barber Expires January 18, 2006 [Page 3] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - because the focus is usually on that component. In instances where - the name server role of this entity requires mentioning, this memo - uses the term "recursive name server". As an example of the - difference, the name server component of a recursive name server - receives DNS queries and the iterative resolver component sends - queries. - - The advent of IPv6 requires mentioning AAAA records as well as A - records when discussing glue. To avoid continuous repetition and - qualification, this memo uses the general term "address record" to - encompass both A and AAAA records when a particular situation is - relevant to both types. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires January 18, 2006 [Page 4] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - -2. Observed iterative resolver misbehavior - -2.1 Aggressive requerying for delegation information - - There can be times when every name server in a zone's NS RRset is - unreachable (e.g., during a network outage), unavailable (e.g., the - name server process is not running on the server host) or - misconfigured (e.g., the name server is not authoritative for the - given zone, also known as "lame"). Consider an iterative resolver - that attempts to resolve a query for a domain name in such a zone and - discovers that none of the zone's name servers can provide an answer. - We have observed a recursive name server implementation whose - iterative resolver then verifies the zone's NS RRset in its cache by - querying for the zone's delegation information: it sends a query for - the zone's NS RRset to one of the parent zone's name servers. (Note - that queries with QTYPE=NS are not required by the standard - resolution algorithm described in section 4.3.2 of RFC 1034 [2]. - These NS queries represent this implementation's addition to that - algorithm.) - - For example, suppose that "example.com" has the following NS RRset: - - example.com. IN NS ns1.example.com. - example.com. IN NS ns2.example.com. - - Upon receipt of a query for "www.example.com" and assuming that - neither "ns1.example.com" nor "ns2.example.com" can provide an - answer, this iterative resolver implementation immediately queries a - "com" zone name server for the "example.com" NS RRset to verify it - has the proper delegation information. This implementation performs - this query to a zone's parent zone for each recursive query it - receives that fails because of a completely unresponsive set of name - servers for the target zone. Consider the effect when a popular zone - experiences a catastrophic failure of all its name servers: now every - recursive query for domain names in that zone sent to this recursive - name server implementation results in a query to the failed zone's - parent name servers. On one occasion when several dozen popular - zones became unreachable, the query load on the com/net name servers - increased by 50%. - - We believe this verification query is not reasonable. Consider the - circumstances: When an iterative resolver is resolving a query for a - domain name in a zone it has not previously searched, it uses the - list of name servers in the referral from the target zone's parent. - If on its first attempt to search the target zone, none of the name - servers in the referral is reachable, a verification query to the - parent would be pointless: this query to the parent would come so - quickly on the heels of the referral that it would be almost certain - - - -Larson & Barber Expires January 18, 2006 [Page 5] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - to contain the same list of name servers. The chance of discovering - any new information is slim. - - The other possibility is that the iterative resolver successfully - contacts one of the target zone's name servers and then caches the NS - RRset from the authority section of a response, the proper behavior - according to section 5.4.1 of RFC 2181 [3], because the NS RRset from - the target zone is more trustworthy than delegation information from - the parent zone. If, while processing a subsequent recursive query, - the iterative resolver discovers that none of the name servers - specified in the cached NS RRset is available or authoritative, - querying the parent would be wrong. An NS RRset from the parent zone - would now be less trustworthy than data already in the cache. - - For this query of the parent zone to be useful, the target zone's - entire set of name servers would have to change AND the former set of - name servers would have to be deconfigured or decommissioned AND the - delegation information in the parent zone would have to be updated - with the new set of name servers, all within the TTL of the target - zone's NS RRset. We believe this scenario is uncommon: - administrative best practices dictate that changes to a zone's set of - name servers happen gradually when at all possible, with servers - removed from the NS RRset left authoritative for the zone as long as - possible. The scenarios that we can envision that would benefit from - the parent requery behavior do not outweigh its damaging effects. - - This section should not be understood to claim that all queries to a - zone's parent are bad. In some cases, such queries are not only - reasonable but required. Consider the situation when required - information, such as the address of a name server (i.e., the address - record corresponding to the RDATA of an NS record), has timed out of - an iterative resolver's cache before the corresponding NS record. If - the name of the name server is below the apex of the zone, then the - name server's address record is only available as glue in the parent - zone. For example, consider this NS record: - - example.com. IN NS ns.example.com. - - If a cache has this NS record but not the address record for - "ns.example.com", it is unable to contact the "example.com" zone - directly and must query the "com" zone to obtain the address record. - Note, however, that such a query would not have QTYPE=NS according to - the standard resolution algorithm. - -2.1.1 Recommendation - - An iterative resolver MUST NOT send a query for the NS RRset of a - non-responsive zone to any of the name servers for that zone's parent - - - -Larson & Barber Expires January 18, 2006 [Page 6] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - zone. For the purposes of this injunction, a non-responsive zone is - defined as a zone for which every name server listed in the zone's NS - RRset: - - 1. is not authoritative for the zone (i.e., lame), or, - - 2. returns a server failure response (RCODE=2), or, - - 3. is dead or unreachable according to section 7.2 of RFC 2308 [4]. - - -2.2 Repeated queries to lame servers - - Section 2.1 describes a catastrophic failure: when every name server - for a zone is unable to provide an answer for one reason or another. - A more common occurrence is when a subset of a zone's name servers - are unavailable or misconfigured. Different failure modes have - different expected durations. Some symptoms indicate problems that - are potentially transient; for example, various types of ICMP - unreachable messages because a name server process is not running or - a host or network is unreachable, or a complete lack of a response to - a query. Such responses could be the result of a host rebooting or - temporary outages; these events don't necessarily require any human - intervention and can be reasonably expected to be temporary. - - Other symptoms clearly indicate a condition requiring human - intervention, such as lame server: if a name server is misconfigured - and not authoritative for a zone delegated to it, it is reasonable to - assume that this condition has potential to last longer than - unreachability or unresponsiveness. Consequently, repeated queries - to known lame servers are not useful. In this case of a condition - with potential to persist for a long time, a better practice would be - to maintain a list of known lame servers and avoid querying them - repeatedly in a short interval. - - It should also be noted, however, that some authoritative name server - implementations appear to be lame only for queries of certain types - as described in RFC 4074 [5]. In this case, it makes sense to retry - the "lame" servers for other types of queries, particularly when all - known authoritative name servers appear to be "lame". - -2.2.1 Recommendation - - Iterative resolvers SHOULD cache name servers that they discover are - not authoritative for zones delegated to them (i.e. lame servers). - If this caching is performed, lame servers MUST be cached against the - specific query tuple <zone name, class, server IP address>. Zone - name can be derived from the owner name of the NS record that was - - - -Larson & Barber Expires January 18, 2006 [Page 7] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - referenced to query the name server that was discovered to be lame. - Implementations that perform lame server caching MUST refrain from - sending queries to known lame servers based on a time interval from - when the server is discovered to be lame. A minimum interval of - thirty minutes is RECOMMENDED. - - An exception to this recommendation occurs if all name servers for a - zone are marked lame. In that case, the iterative resolver SHOULD - temporarily ignore the servers' lameness status and query one or more - servers. This behavior is a workaround for the type-specific - lameness issue described in the previous section. - - Implementors should take care not to make lame server avoidance logic - overly broad: note that a name server could be lame for a parent zone - but not a child zone, e.g., lame for "example.com" but properly - authoritative for "sub.example.com". Therefore a name server should - not be automatically considered lame for subzones. In the case - above, even if a name server is known to be lame for "example.com", - it should be queried for QNAMEs at or below "sub.example.com" if an - NS record indicates it should be authoritative for that zone. - -2.3 Inability to follow multiple levels of indirection - - Some iterative resolver implementations are unable to follow - sufficient levels of indirection. For example, consider the - following delegations: - - foo.example. IN NS ns1.example.com. - foo.example. IN NS ns2.example.com. - - example.com. IN NS ns1.test.example.net. - example.com. IN NS ns2.test.example.net. - - test.example.net. IN NS ns1.test.example.net. - test.example.net. IN NS ns2.test.example.net. - - An iterative resolver resolving the name "www.foo.example" must - follow two levels of indirection, first obtaining address records for - "ns1.test.example.net" or "ns2.test.example.net" in order to obtain - address records for "ns1.example.com" or "ns2.example.com" in order - to query those name servers for the address records of - "www.foo.example". While this situation may appear contrived, we - have seen multiple similar occurrences and expect more as new generic - top-level domains (gTLDs) become active. We anticipate many zones in - new gTLDs will use name servers in existing gTLDs, increasing the - number of delegations using out-of-zone name servers. - - - - - -Larson & Barber Expires January 18, 2006 [Page 8] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - -2.3.1 Recommendation - - Clearly constructing a delegation that relies on multiple levels of - indirection is not a good administrative practice. However, the - practice is widespread enough to require that iterative resolvers be - able to cope with it. Iterative resolvers SHOULD be able to handle - arbitrary levels of indirection resulting from out-of-zone name - servers. Iterative resolvers SHOULD implement a level-of-effort - counter to avoid loops or otherwise performing too much work in - resolving pathological cases. - - A best practice that avoids this entire issue of indirection is to - name one or more of a zone's name servers in the zone itself. For - example, if the zone is named "example.com", consider naming some of - the name servers "ns{1,2,...}.example.com" (or similar). - -2.4 Aggressive retransmission when fetching glue - - When an authoritative name server responds with a referral, it - includes NS records in the authority section of the response. - According to the algorithm in section 4.3.2 of RFC 1034 [2], the name - server should also "put whatever addresses are available into the - additional section, using glue RRs if the addresses are not available - from authoritative data or the cache." Some name server - implementations take this address inclusion a step further with a - feature called "glue fetching". A name server that implements glue - fetching attempts to include address records for every NS record in - the authority section. If necessary, the name server issues multiple - queries of its own to obtain any missing address records. - - Problems with glue fetching can arise in the context of - "authoritative-only" name servers, which only serve authoritative - data and ignore requests for recursion. Such an entity will not - normally generate any queries of its own. Instead it answers non- - recursive queries from iterative resolvers looking for information in - zones it serves. With glue fetching enabled, however, an - authoritative server invokes an iterative resolver to look up an - unknown address record to complete the additional section of a - response. - - We have observed situations where the iterative resolver of a glue- - fetching name server can send queries that reach other name servers, - but is apparently prevented from receiving the responses. For - example, perhaps the name server is authoritative-only and therefore - its administrators expect it to receive only queries and not - responses. Perhaps unaware of glue fetching and presuming that the - name server's iterative resolver will generate no queries, its - administrators place the name server behind a network device that - - - -Larson & Barber Expires January 18, 2006 [Page 9] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - prevents it from receiving responses. If this is the case, all glue- - fetching queries will go answered. - - We have observed name server implementations whose iterative - resolvers retry excessively when glue-fetching queries are - unanswered. A single com/net name server has received hundreds of - queries per second from a single such source. Judging from the - specific queries received and based on additional analysis, we - believe these queries result from overly aggressive glue fetching. - -2.4.1 Recommendation - - Implementers whose name servers support glue fetching SHOULD take - care to avoid sending queries at excessive rates. Implementations - SHOULD support throttling logic to detect when queries are sent but - no responses are received. - -2.5 Aggressive retransmission behind firewalls - - A common occurrence and one of the largest sources of repeated - queries at the com/net and root name servers appears to result from - resolvers behind misconfigured firewalls. In this situation, an - iterative resolver is apparently allowed to send queries through a - firewall to other name servers, but not receive the responses. The - result is more queries than necessary because of retransmission, all - of which are useless because the responses are never received. Just - as with the glue-fetching scenario described in Section 2.4, the - queries are sometimes sent at excessive rates. To make matters - worse, sometimes the responses, sent in reply to legitimate queries, - trigger an alarm on the originator's intrusion detection system. We - are frequently contacted by administrators responding to such alarms - who believe our name servers are attacking their systems. - - Not only do some resolvers in this situation retransmit queries at an - excessive rate, but they continue to do so for days or even weeks. - This scenario could result from an organization with multiple - recursive name servers, only a subset of whose iterative resolvers' - traffic is improperly filtered in this manner. Stub resolvers in the - organization could be configured to query multiple recursive name - servers. Consider the case where a stub resolver queries a filtered - recursive name server first. The iterative resolver of this - recursive name server sends one or more queries whose replies are - filtered, so it can't respond to the stub resolver, which times out. - Then the stub resolver retransmits to a recursive name server that is - able to provide an answer. Since resolution ultimately succeeds the - underlying problem might not be recognized or corrected. A popular - stub resolver implementation has a very aggressive retransmission - schedule, including simultaneous queries to multiple recursive name - - - -Larson & Barber Expires January 18, 2006 [Page 10] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - servers, which could explain how such a situation could persist - without being detected. - -2.5.1 Recommendation - - The most obvious recommendation is that administrators SHOULD take - care not to place iterative resolvers behind a firewall that allows - queries to pass through but not the resulting replies. - - Iterative resolvers SHOULD take care to avoid sending queries at - excessive rates. Implementations SHOULD support throttling logic to - detect when queries are sent but no responses are received. - -2.6 Misconfigured NS records - - Sometimes a zone administrator forgets to add the trailing dot on the - domain names in the RDATA of a zone's NS records. Consider this - fragment of the zone file for "example.com": - - $ORIGIN example.com. - example.com. 3600 IN NS ns1.example.com ; Note missing - example.com. 3600 IN NS ns2.example.com ; trailing dots - - The zone's authoritative servers will parse the NS RDATA as - "ns1.example.com.example.com" and "ns2.example.com.example.com" and - return NS records with this incorrect RDATA in responses, including - typically the authority section of every response containing records - from the "example.com" zone. - - Now consider a typical sequence of queries. An iterative resolver - attempting to resolve address records for "www.example.com" with no - cached information for this zone will query a "com" authoritative - server. The "com" server responds with a referral to the - "example.com" zone, consisting of NS records with valid RDATA and - associated glue records. (This example assumes that the - "example.com" zone delegation information is correct in the "com" - zone.) The iterative resolver caches the NS RRset from the "com" - server and follows the referral by querying one of the "example.com" - authoritative servers. This server responds with the - "www.example.com" address record in the answer section and, - typically, the "example.com" NS records in the authority section and, - if space in the message remains, glue address records in the - additional section. According to Section 5.4 of RFC 2181 [3], NS - records in the authority section of an authoritative answer are more - trustworthy than NS records from the authority section of a non- - authoritative answer. Thus the "example.com" NS RRset just received - from the "example.com" authoritative server overrides the - "example.com" NS RRset received moments ago from the "com" - - - -Larson & Barber Expires January 18, 2006 [Page 11] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - authoritative server. - - But the "example.com" zone contains the erroneous NS RRset as shown - in the example above. Subsequent queries for names in "example.com" - will cause the iterative resolver to attempt to use the incorrect NS - records and so it will try to resolve the nonexistent names - "ns1.example.com.example.com" and "ns2.example.com.example.com". In - this example, since all of the zone's name servers are named in the - zone itself (i.e., "ns1.example.com.example.com" and - "ns2.example.com.example.com" both end in "example.com") and all are - bogus, the iterative resolver cannot reach any "example.com" name - servers. Therefore attempts to resolve these names result in address - record queries to the "com" authoritative servers. Queries for such - obviously bogus glue address records occur frequently at the com/net - name servers. - -2.6.1 Recommendation - - An authoritative server can detect this situation. A trailing dot - missing from an NS record's RDATA always results by definition in a - name server name that exists somewhere under the apex of the zone the - NS record appears in. Note that further levels of delegation are - possible, so a missing trailing dot could inadvertently create a name - server name that actually exists in a subzone. - - An authoritative name server SHOULD issue a warning when one of a - zone's NS records references a name server below the zone's apex when - a corresponding address record does not exist in the zone AND there - are no delegated subzones where the address record could exist. - -2.7 Name server records with zero TTL - - Sometimes a popular com/net subdomain's zone is configured with a TTL - of zero on the zone's NS records, which prohibits these records from - being cached and will result in a higher query volume to the zone's - authoritative servers. The zone's administrator should understand - the consequences of such a configuration and provision resources - accordingly. A zero TTL on the zone's NS RRset, however, carries - additional consequences beyond the zone itself: if an iterative - resolver cannot cache a zone's NS records because of a zero TTL, it - will be forced to query that zone's parent's name servers each time - it resolves a name in the zone. The com/net authoritative servers do - see an increased query load when a popular com/net subdomain's zone - is configured with a TTL of zero on the zone's NS records. - - A zero TTL on an RRset expected to change frequently is extreme but - permissible. A zone's NS RRset is a special case, however, because - changes to it must be coordinated with the zone's parent. In most - - - -Larson & Barber Expires January 18, 2006 [Page 12] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - zone parent/child relationships we are aware of, there is typically - some delay involved in effecting changes. Further, changes to the - set of a zone's authoritative name servers (and therefore to the - zone's NS RRset) are typically relatively rare: providing reliable - authoritative service requires a reasonably stable set of servers. - Therefore an extremely low or zero TTL on a zone's NS RRset rarely - makes sense, except in anticipation of an upcoming change. In this - case, when the zone's administrator has planned a change and does not - want iterative resolvers throughout the Internet to cache the NS - RRset for a long period of time, a low TTL is reasonable. - -2.7.1 Recommendation - - Because of the additional load placed on a zone's parent's - authoritative servers resulting from a zero TTL on a zone's NS RRset, - under such circumstances authoritative name servers SHOULD issue a - warning when loading a zone. - -2.8 Unnecessary dynamic update messages - - The UPDATE message specified in RFC 2136 [6] allows an authorized - agent to update a zone's data on an authoritative name server using a - DNS message sent over the network. Consider the case of an agent - desiring to add a particular resource record. Because of zone cuts, - the agent does not necessarily know the proper zone to which the - record should be added. The dynamic update process requires that the - agent determine the appropriate zone so the UPDATE message can be - sent to one of the zone's authoritative servers (typically the - primary master as specified in the zone's SOA MNAME field). - - The appropriate zone to update is the closest enclosing zone, which - cannot be determined only by inspecting the domain name of the record - to be updated, since zone cuts can occur anywhere. One way to - determine the closest enclosing zone entails walking up the name - space tree by sending repeated UPDATE messages until success. For - example, consider an agent attempting to add an address record with - the name "foo.bar.example.com". The agent could first attempt to - update the "foo.bar.example.com" zone. If the attempt failed, the - update could be directed to the "bar.example.com" zone, then the - "example.com" zone, then the "com" zone, and finally the root zone. - - A popular dynamic agent follows this algorithm. The result is many - UPDATE messages received by the root name servers, the com/net - authoritative servers, and presumably other TLD authoritative - servers. A valid question is why the algorithm proceeds to send - updates all the way to TLD and root name servers. This behavior is - not entirely unreasonable: in enterprise DNS architectures with an - "internal root" design, there could conceivably be private, non- - - - -Larson & Barber Expires January 18, 2006 [Page 13] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - public TLD or root zones that would be the appropriate targets for a - dynamic update. - - A significant deficiency with this algorithm is that knowledge of a - given UPDATE message's failure is not helpful in directing future - UPDATE messages to the appropriate servers. A better algorithm would - be to find the closest enclosing zone by walking up the name space - with queries for SOA or NS rather than "probing" with UPDATE - messages. Once the appropriate zone is found, an UPDATE message can - be sent. In addition, the results of these queries can be cached to - aid in determining closest enclosing zones for future updates. Once - the closest enclosing zone is determined with this method, the update - will either succeed or fail and there is no need to send further - updates to higher-level zones. The important point is that walking - up the tree with queries yields cacheable information, whereas - walking up the tree by sending UPDATE messages does not. - -2.8.1 Recommendation - - Dynamic update agents SHOULD send SOA or NS queries to progressively - higher-level names to find the closest enclosing zone for a given - name to update. Only after the appropriate zone is found should the - client send an UPDATE message to one of the zone's authoritative - servers. Update clients SHOULD NOT "probe" using UPDATE messages by - walking up the tree to progressively higher-level zones. - -2.9 Queries for domain names resembling IPv4 addresses - - The root name servers receive a significant number of A record - queries where the QNAME looks like an IPv4 address. The source of - these queries is unknown. It could be attributed to situations where - a user believes an application will accept either a domain name or an - IP address in a given configuration option. The user enters an IP - address, but the application assumes any input is a domain name and - attempts to resolve it, resulting in an A record lookup. There could - also be applications that produce such queries in a misguided attempt - to reverse map IP addresses. - - These queries result in Name Error (RCODE=3) responses. An iterative - resolver can negatively cache such responses, but each response - requires a separate cache entry, i.e., a negative cache entry for the - domain name "192.0.2.1" does not prevent a subsequent query for the - domain name "192.0.2.2". - -2.9.1 Recommendation - - It would be desirable for the root name servers not to have to answer - these queries: they unnecessarily consume CPU resources and network - - - -Larson & Barber Expires January 18, 2006 [Page 14] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - bandwidth. A possible solution is to delegate these numeric TLDs - from the root zone to a separate set of servers to absorb the - traffic. The "black hole servers" used by the AS 112 Project [8], - which are currently delegated the in-addr.arpa zones corresponding to - RFC 1918 [7] private use address space, would be a possible choice to - receive these delegations. Of course, the proper and usual root zone - change procedures would have to be followed to make such a change to - the root zone. - -2.10 Misdirected recursive queries - - The root name servers receive a significant number of recursive - queries (i.e., queries with the RD bit set in the header). Since - none of the root servers offers recursion, the servers' response in - such a situation ignores the request for recursion and the response - probably does not contain the data the querier anticipated. Some of - these queries result from users configuring stub resolvers to query a - root server. (This situation is not hypothetical: we have received - complaints from users when this configuration does not work as - hoped.) Of course, users should not direct stub resolvers to use - name servers that do not offer recursion, but we are not aware of any - stub resolver implementation that offers any feedback to the user - when so configured, aside from simply "not working". - -2.10.1 Recommendation - - When the IP address of a name server that supposedly offers recursion - is configured in a stub resolver using an interactive user interface, - the resolver could send a test query to verify that the server indeed - supports recursion (i.e., verify that the response has the RA bit set - in the header). The user could be immediately notified if the server - is non-recursive. - - The stub resolver could also report an error, either through a user - interface or in a log file, if the queried server does not support - recursion. Error reporting SHOULD be throttled to avoid a - notification or log message for every response from a non-recursive - server. - -2.11 Suboptimal name server selection algorithm - - An entire document could be devoted to the topic of problems with - different implementations of the recursive resolution algorithm. The - entire process of recursion is woefully under specified, requiring - each implementor to design an algorithm. Sometimes implementors make - poor design choices that could be avoided if a suggested algorithm - and best practices were documented, but that is a topic for another - document. - - - -Larson & Barber Expires January 18, 2006 [Page 15] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - Some deficiencies cause significant operational impact and are - therefore worth mentioning here. One of these is name server - selection by an iterative resolver. When an iterative resolver wants - to contact one of a zone's authoritative name servers, how does it - choose from the NS records listed in the zone's NS RRset? If the - selection mechanism is suboptimal, queries are not spread evenly - among a zone's authoritative servers. The details of the selection - mechanism are up to the implementor, but we offer some suggestions. - -2.11.1 Recommendation - - This list is not conclusive, but reflects the changes that would - produce the most impact in terms of reducing disproportionate query - load among a zone's authoritative servers. I.e., these changes would - help spread the query load evenly. - - o Do not make assumptions based on NS RRset order: all NS RRs SHOULD - be treated equally. (In the case of the "com" zone, for example, - most of the root servers return the NS record for "a.gtld- - servers.net" first in the authority section of referrals. - Apparently as a result, this server receives disproportionately - more traffic than the other 12 authoritative servers for "com".) - - o Use all NS records in an RRset. (For example, we are aware of - implementations that hard-coded information for a subset of the - root servers.) - - o Maintain state and favor the best-performing of a zone's - authoritative servers. A good definition of performance is - response time. Non-responsive servers can be penalized with an - extremely high response time. - - o Do not lock onto the best-performing of a zone's name servers. An - iterative resolver SHOULD periodically check the performance of - all of a zone's name servers to adjust its determination of the - best-performing one. - - - - - - - - - - - - - - - -Larson & Barber Expires January 18, 2006 [Page 16] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - -3. IANA considerations - - There are no new IANA considerations introduced by this memo. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires January 18, 2006 [Page 17] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - -4. Security considerations - - The iterative resolver misbehavior discussed in this document exposes - the root and TLD name servers to increased risk of both intentional - and unintentional denial of service attacks. - - We believe that implementation of the recommendations offered in this - document will reduce the amount of unnecessary traffic seen at root - and TLD name servers, thus reducing the opportunity for an attacker - to use such queries to his or her advantage. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires January 18, 2006 [Page 18] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - -5. Internationalization considerations - - There are no new internationalization considerations introduced by - this memo. - -6. Informative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - - [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS - Queries for IPv6 Addresses", RFC 4074, May 2005. - - [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. - Lear, "Address Allocation for Private Internets", BCP 5, - RFC 1918, February 1996. - - [8] <http://www.as112.net> - - -Authors' Addresses - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - Email: mlarson@verisign.com - - - - - - - - - -Larson & Barber Expires January 18, 2006 [Page 19] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - - Piet Barber - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - Email: pbarber@verisign.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires January 18, 2006 [Page 20] - -Internet-Draft Observed DNS Resolution Misbehavior July 2005 - - -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 (2005). 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. - - - - -Larson & Barber Expires January 18, 2006 [Page 21] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt deleted file mode 100644 index a5d0d60..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt +++ /dev/null @@ -1,1736 +0,0 @@ - - - -DNSOP O. Kolkman -Internet-Draft RIPE NCC -Expires: September 2, 2005 R. Gieben - NLnet Labs - March 2005 - - - DNSSEC Operational Practices - draft-ietf-dnsop-dnssec-operational-practices-04.txt - -Status of this Memo - - 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 becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 2, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document describes a set of practices for operating the DNS with - security extensions (DNSSEC). The target audience is zone - administrators deploying DNSSEC. - - The document discusses operational aspects of using keys and - signatures in the DNS. It discusses issues as key generation, key - storage, signature generation, key rollover and related policies. - - - -Kolkman & Gieben Expires September 2, 2005 [Page 1] - -Internet-Draft DNSSEC Operational Practices March 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 4 - 1.2 Time Definitions . . . . . . . . . . . . . . . . . . . . . 5 - 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5 - 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6 - 3.1 Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6 - 3.1.1 Motivations for the KSK and ZSK Separation . . . . . . 6 - 3.1.2 KSKs for high level zones . . . . . . . . . . . . . . 7 - 3.2 Randomness . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.3 Key Effectivity Period . . . . . . . . . . . . . . . . . . 8 - 3.4 Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9 - 3.5 Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.6 Private Key Storage . . . . . . . . . . . . . . . . . . . 10 - 4. Signature generation, Key Rollover and Related Policies . . . 11 - 4.1 Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 11 - 4.1.1 Time Considerations . . . . . . . . . . . . . . . . . 11 - 4.2 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 13 - 4.2.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 13 - 4.2.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 17 - 4.2.3 Difference Between ZSK and KSK Rollovers . . . . . . . 18 - 4.2.4 Automated Key Rollovers . . . . . . . . . . . . . . . 19 - 4.3 Planning for Emergency Key Rollover . . . . . . . . . . . 19 - 4.3.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . 20 - 4.3.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . 20 - 4.3.3 Compromises of Keys Anchored in Resolvers . . . . . . 20 - 4.4 Parental Policies . . . . . . . . . . . . . . . . . . . . 21 - 4.4.1 Initial Key Exchanges and Parental Policies - Considerations . . . . . . . . . . . . . . . . . . . . 21 - 4.4.2 Storing Keys or Hashes? . . . . . . . . . . . . . . . 21 - 4.4.3 Security Lameness . . . . . . . . . . . . . . . . . . 22 - 4.4.4 DS Signature Validity Period . . . . . . . . . . . . . 22 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 7.1 Normative References . . . . . . . . . . . . . . . . . . . 24 - 7.2 Informative References . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 - A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 25 - B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 26 - C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 26 - D. Document Details and Changes . . . . . . . . . . . . . . . . . 29 - D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 29 - D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 29 - D.3 draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 29 - D.4 draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 29 - D.5 draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 30 - - - -Kolkman & Gieben Expires September 2, 2005 [Page 2] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - Intellectual Property and Copyright Statements . . . . . . . . 31 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 3] - -Internet-Draft DNSSEC Operational Practices March 2005 - - -1. Introduction - - During workshops and early operational deployment tests, operators - and system administrators gained experience about operating the DNS - with security extensions (DNSSEC). This document translates these - experiences into a set of practices for zone administrators. At the - time of writing, there exists very little experience with DNSSEC in - production environments; this document should therefore explicitly - not be seen as representing 'Best Current Practices'. - - The procedures herein are focused on the maintenance of signed zones - (i.e. signing and publishing zones on authoritative servers). It is - intended that maintenance of zones such as resigning or key rollovers - be transparent to any verifying clients on the Internet. - - The structure of this document is as follows. In Section 2 we - discuss the importance of keeping the "chain of trust" intact. - Aspects of key generation and storage of private keys are discussed - in Section 3; the focus in this section is mainly on the private part - of the key(s). Section 4 describes considerations concerning the - public part of the keys. Since these public keys appear in the DNS - one has to take into account all kinds of timing issues, which are - discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the - rollover, or which, of keys. Finally Section 4.4 discusses - considerations on how parents deal with their children's public keys - in order to maintain chains of trust. - - The typographic conventions used in this document are explained in - Appendix C. - - Since this is a document with operational suggestions and there are - no protocol specifications, the RFC2119 [4] language does not apply. - - This document obsoletes RFC2541 [7] - -1.1 The Use of the Term 'key' - - It is assumed that the reader is familiar with the concept of - asymmetric keys on which DNSSEC is based (Public Key Cryptography - [11]). Therefore, this document will use the term 'key' rather - loosely. Where it is written that 'a key is used to sign data' it is - assumed that the reader understands that it is the private part of - the key-pair that is used for signing. It is also assumed that the - reader understands that the public part of the key-pair is published - in the DNSKEY resource record and that it is the public part that is - used in key-exchanges. - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 4] - -Internet-Draft DNSSEC Operational Practices March 2005 - - -1.2 Time Definitions - - In this document we will be using a number of time related terms. - The following definitions apply: - o "Signature validity period" - The period that a signature is valid. It starts at the time - specified in the signature inception field of the RRSIG RR and - ends at the time specified in the expiration field of the RRSIG - RR. - o "Signature publication period" - Time after which a signature (made with a specific key) is - replaced with a new signature (made with the same key). This - replacement takes place by publishing the relevant RRSIG in the - master zone file. - After one stopped publishing an RRSIG in a zone it may take a - while before the RRSIG has expired from caches and has actually - been removed from the DNS. - o "Key effectivity period" - The period which a key pair is expected to be effective. This - period is defined as the time between the first inception time - stamp and the last expiration date of any signature made with - this key. - The key effectivity period can span multiple signature validity - periods. - o "Maximum/Minimum Zone TTL" - The maximum or minimum value of the TTLs from the complete set - of RRs in a zone. - -2. Keeping the Chain of Trust Intact - - Maintaining a valid chain of trust is important because broken chains - of trust will result in data being marked as Bogus (as defined in [2] - section 5), which may cause entire (sub)domains to become invisible - to verifying clients. The administrators of secured zones have to - realize that their zone is, to their clients, part of a chain of - trust. - - As mentioned in the introduction, the procedures herein are intended - to ensure maintenance of zones, such as resigning or key rollovers, - will be transparent to the verifying clients on the Internet. - - Administrators of secured zones will have to keep in mind that data - published on an authoritative primary server will not be immediately - seen by verifying clients; it may take some time for the data to be - transfered to other secondary authoritative nameservers and clients - may be fetching data from caching non-authoritative servers. - - For the verifying clients it is important that data from secured - - - -Kolkman & Gieben Expires September 2, 2005 [Page 5] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - zones can be used to build chains of trust regardless of whether the - data came directly from an authoritative server, a caching nameserver - or some middle box. Only by carefully using the available timing - parameters can a zone administrator assure that the data necessary - for verification can be obtained. - - The responsibility for maintaining the chain of trust is shared by - administrators of secured zones in the chain of trust. This is most - obvious in the case of a 'key compromise' when a trade off between - maintaining a valid chain of trust and replacing the compromised keys - as soon as possible must be made. Then zone administrators will have - to make a trade off, between keeping the chain of trust intact - - thereby allowing for attacks with the compromised key - or to - deliberately break the chain of trust and making secured sub domains - invisible to security aware resolvers. Also see Section 4.3. - -3. Keys Generation and Storage - - This section describes a number of considerations with respect to the - security of keys. It deals with the generation, effectivity period, - size and storage of private keys. - -3.1 Zone and Key Signing Keys - - The DNSSEC validation protocol does not distinguish between DNSKEYs. - All DNSKEYs can be used during the validation. In practice operators - use Key Signing and Zone Signing Keys and use the so-called (Secure - Entry Point) SEP flag to distinguish between them during operations. - The dynamics and considerations are discussed below. - - To make zone resigning and key rollover procedures easier to - implement, it is possible to use one or more keys as Key Signing Keys - (KSK). These keys will only sign the apex DNSKEY RR set in a zone. - Other keys can be used to sign all the RRsets in a zone and are - referred to as Zone Signing Keys (ZSK). In this document we assume - that KSKs are the subset of keys that are used for key exchanges with - the parent and potentially for configuration as trusted anchors - the - SEP keys. In this document we assume a one-to-one mapping between - KSK and SEP keys and we assume the SEP flag [1] to be set on all - KSKs. - -3.1.1 Motivations for the KSK and ZSK Separation - - Differentiating between the KSK and ZSK functions has several - advantages: - - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 6] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - o No parent/child interaction is required when ZSKs are updated. - o The KSK can be made stronger (i.e. using more bits in the key - material). This has little operational impact since it is only - used to sign a small fraction of the zone data. Also when - verifying the KSK is only used to verify the zone's keyset. - o As the KSK is only used to sign a key set, which is most probably - updated less frequently than other data in the zone, it can be - stored separately from and in a safer location than the ZSK. - o A KSK can have a longer key effectivity period. - - For almost any method of key management and zone signing the KSK is - used less frequently than the ZSK. Once a key set is signed with the - KSK all the keys in the key set can be used as ZSK. If a ZSK is - compromised, it can be simply dropped from the key set. The new key - set is then resigned with the KSK. - - Given the assumption that for KSKs the SEP flag is set, the KSK can - be distinguished from a ZSK by examining the flag field in the DNSKEY - RR. If the flag field is an odd number it is a KSK. If it is an - even number it is a ZSK. - - The zone-signing key can be used to sign all the data in a zone on a - regular basis. When a zone-signing key is to be rolled, no - interaction with the parent is needed. This allows for "Signature - Validity Periods" on the order of days. - - The key-signing key is only to be used to sign the DNSKEY RRs in a - zone. If a key-signing key is to be rolled over, there will be - interactions with parties other than the zone administrator. These - can include the registry of the parent zone or administrators of - verifying resolvers that have the particular key configured as - trusted entry points. Hence, the key effectivity period of these - keys can and should be made much longer. Although, given a long - enough key, the Key Usage Time can be on the order of years we - suggest planning for a key effectivity of the order of a few months - so that a key rollover remains an operational routine. - -3.1.2 KSKs for high level zones - - Higher level zones are generally more sensitive than lower level - zones. Anyone controlling or breaking the security of a zone thereby - obtains authority over all of its sub domains (except in the case of - resolvers that have locally configured the public key of a sub - domain). Therefore, extra care should be taken with high level zones - and strong keys used. - - The root zone is the most critical of all zones. Someone controlling - or compromising the security of the root zone would control the - - - -Kolkman & Gieben Expires September 2, 2005 [Page 7] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - entire DNS name space of all resolvers using that root zone (except - in the case of resolvers that have locally configured the public key - of a sub domain). Therefore, the utmost care must be taken in the - securing of the root zone. The strongest and most carefully handled - keys should be used. The root zone private key should always be kept - off line. - - Many resolvers will start at a root server for their access to and - authentication of DNS data. Securely updating the trust anchors in - an enormous population of resolvers around the world will be - extremely difficult. - -3.2 Randomness - - Careful generation of all keys is a sometimes overlooked but - absolutely essential element in any cryptographically secure system. - The strongest algorithms used with the longest keys are still of no - use if an adversary can guess enough to lower the size of the likely - key space so that it can be exhaustively searched. Technical - suggestions for the generation of random keys will be found in - RFC1750 [3]. One should carefully assess if the random number - generator used during key generation adheres to these suggestions. - - Keys with a long effectivity period are particularly sensitive as - they will represent a more valuable target and be subject to attack - for a longer time than short period keys. It is strongly recommended - that long term key generation occur off-line in a manner isolated - from the network via an air gap or, at a minimum, high level secure - hardware. - -3.3 Key Effectivity Period - - For various reasons keys in DNSSEC need to be changed once in a - while. The longer a key is in use, the greater the probability that - it will have been compromised through carelessness, accident, - espionage, or cryptanalysis. Furthermore when key rollovers are too - rare an event, they will not become part of the operational habit and - there is risk that nobody on-site will remember the procedure for - rollover when the need is there. - - For Key Signing Keys a reasonable key effectivity period is 13 - months, with the intent to replace them after 12 months. An intended - key effectivity period of a month is reasonable for Zone Signing - Keys. - - Using these recommendations will lead to rollovers occurring - frequently enough to become part of 'operational habits'; the - procedure does not have to be reinvented every time a key is - - - -Kolkman & Gieben Expires September 2, 2005 [Page 8] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - replaced. - - Key effectivity periods can be made very short, as in the order of a - few minutes. But when replacing keys one has to take the - considerations from Section 4.1 and Section 4.2 into account. - -3.4 Key Algorithm - - There are currently three different types of algorithms that can be - used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter - is fairly new and still needs to be standardized for usage in DNSSEC. - - RSA has been developed in an open and transparent manner. As the - patent on RSA expired in 2000, its use is now also free. - - DSA has been developed by NIST. The creation of signatures is - roughly done at the same speed as with RSA, but is 10 to 40 times as - slow for verification [11]. - - We suggest the use of RSA/SHA-1 as the preferred algorithm for the - key. The current known attacks on RSA can be defeated by making your - key longer. As the MD5 hashing algorithm is showing (theoretical) - cracks, we recommend the usage of SHA1. - - In 2005 some discoveries were made that SHA-1 also has some - weaknesses. Currently SHA-1 is strong enough for DNSSEC. It is - expected that a new hashing algorithm is rolled out, before any - attack becomes practical. - -3.5 Key Sizes - - When choosing key sizes, zone administrators will need to take into - account how long a key will be used and how much data will be signed - during the key publication period. It is hard to give precise - recommendations but Lenstra and Verheul [10] supplied the following - table with lower bound estimates for cryptographic key sizes. Their - recommendations are based on a set of explicitly formulated parameter - settings, combined with existing data points about cryptographic - systems. For details we refer to the original paper. - - - - - - - - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 9] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - Year RSA Key Sizes Year RSA Key Sizes - - 2000 952 2015 1613 - 2001 990 2016 1664 - 2002 1028 2017 1717 - 2003 1068 2018 1771 - 2004 1108 2019 1825 - - - 2005 1149 2020 1881 - 2006 1191 2021 1937 - 2007 1235 2022 1995 - 2008 1279 2023 2054 - 2009 1323 2024 2113 - - - 2026 2236 2025 2174 - 2010 1369 2027 2299 - 2011 1416 2028 2362 - 2012 1464 2029 2427 - 2013 1513 - 2014 1562 - - For example, should you wish your key to last three years from 2003, - check the RSA key size values for 2006 in this table. In this case - it should be at least 1191 bits. - - Please keep in mind that nobody can see into the future, and that - these key lengths are only provided here as a guide. - - When determining a key size one should take into account that a large - key will be slower during generation and verification. For RSA, - verification, the most common operation, will vary roughly with the - square of the key size; signing will vary with the cube of the key - size length; and key generation will vary with the fourth power of - the modulus length. Besides larger keys will increase the sizes of - the RRSIG and DNSKEY records and will therefore increase the chance - of DNS UDP packet overflow. Also see Section 3.1.1 for a discussion - of how keys serving different roles (ZSK v. KSK) may need different - key strengths. - -3.6 Private Key Storage - - It is recommended that, where possible, zone private keys and the - zone file master copy be kept and used in off-line, non-network - connected, physically secure machines only. Periodically an - application can be run to add authentication to a zone by adding - RRSIG and NSEC RRs. Then the augmented file can be transferred, - - - -Kolkman & Gieben Expires September 2, 2005 [Page 10] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - perhaps by sneaker-net, to the networked zone primary server machine. - - The ideal situation is to have a one way information flow to the - network to avoid the possibility of tampering from the network. - Keeping the zone master file on-line on the network and simply - cycling it through an off-line signer does not do this. The on-line - version could still be tampered with if the host it resides on is - compromised. For maximum security, the master copy of the zone file - should be off net and should not be updated based on an unsecured - network mediated communication. - - In general keeping a zone-file off-line will not be practical and the - machines on which zone files are maintained will be connected to a - network. Operators are advised to take security measures to shield - unauthorized access to the master copy. - - For dynamically updated secured zones [5] both the master copy and - the private key that is used to update signatures on updated RRs will - need to be on line. - -4. Signature generation, Key Rollover and Related Policies - -4.1 Time in DNSSEC - - Without DNSSEC all times in DNS are relative. The SOA RR's refresh, - retry and expiration timers are counters that are used to determine - the time elapsed after a slave server synchronized (or tried to - synchronize) with a master server. The Time to Live (TTL) value and - the SOA RR minimum TTL parameter [6] are used to determine how long a - forwarder should cache data after it has been fetched from an - authoritative server. By using a signature validity period, DNSSEC - introduces the notion of an absolute time in the DNS. Signatures in - DNSSEC have an expiration date after which the signature is marked as - invalid and the signed data is to be considered Bogus. - -4.1.1 Time Considerations - - Because of the expiration of signatures, one should consider the - following: - o We suggest the Maximum Zone TTL of your zone data to be a fraction - of your signature validity period. - If the TTL would be of similar order as the signature validity - period, then all RRsets fetched during the validity period - would be cached until the signature expiration time. Section - 7.1 of [2] suggests that "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". As a result - query load on authoritative servers would peak at signature - - - -Kolkman & Gieben Expires September 2, 2005 [Page 11] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - expiration time, as this is also the time at which records - simultaneously expire from caches. - To avoid query load peaks we suggest the TTL on all the RRs in - your zone to be at least a few times smaller than your - signature validity period. - o We suggest the signature publication period to be at least one - maximum TTL smaller than the signature validity period. - Resigning a zone shortly before the end of the signature - validity period may cause simultaneous expiration of data from - caches. This in turn may lead to peaks in the load on - authoritative servers. - o We suggest the minimum zone TTL to be long enough to both fetch - and verify all the RRs in the authentication chain. A low TTL - could cause two problems: - 1. During validation, some data may expire before the - validation is complete. The validator should be able to keep - all data, until is completed. This applies to all RRs needed - to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the - final answers i.e. the RR set that is returned for the initial - query. - 2. Frequent verification causes load on recursive nameservers. - Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from - caching. The TTL on those should be relatively long. - o Slave servers will need to be able to fetch newly signed zones - well before the RRSIGs in the zone served by the slave server pass - their signature expiration time. - When a slave server is out of sync with its master and data in - a zone is signed by expired signatures it may be better for the - slave server not to give out any answer. - Normally a slave server that is not able to contact a master - server for an extended period will expire a zone. When that - happens the zone will not respond on queries. The time of - expiration is set in the SOA record and is relative to the last - successful refresh between the master and the slave server. - There exists no coupling between the signature expiration of - RRSIGs in the zone and the expire parameter in the SOA. - If the server serves a DNSSEC zone than it may well happen that - the signatures expire well before the SOA expiration timer - counts down to zero. It is not possible to completely prevent - this from happening by tweaking the SOA parameters. - However, the effects can be minimized where the SOA expiration - time is equal or smaller than the signature validity period. - The consequence of an authoritative server not being able to - update a zone, whilst that zone includes expired signatures, is - that non-secure resolvers will continue to be able to resolve - data served by the particular slave servers while security - aware resolvers will experience problems because of answers - being marked as Bogus. - - - -Kolkman & Gieben Expires September 2, 2005 [Page 12] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - We suggest the SOA expiration timer being approximately one - third or one fourth of the signature validity period. It will - allow problems with transfers from the master server to be - noticed before the actual signature time out. - We also suggest that operators of nameservers that supply - secondary services develop 'watch dogs' to spot upcoming - signature expirations in zones they slave, and take appropriate - action. - When determining the value for the expiration parameter one has - to take the following into account: What are the chances that - all my secondary zones expire; How quickly can I reach an - administrator of secondary servers to load a valid zone? All - these arguments are not DNSSEC specific but may influence the - choice of your signature validity intervals. - -4.2 Key Rollovers - - A DNSSEC key cannot be used forever (see Section 3.3). So key - rollovers -- or supercessions, as they are sometimes called -- are a - fact of life when using DNSSEC. Zone administrators who are in the - process of rolling their keys have to take into account that data - published in previous versions of their zone still lives in caches. - When deploying DNSSEC, this becomes an important consideration; - ignoring data that may be in caches may lead to loss of service for - clients. - - The most pressing example of this is when zone material signed with - an old key is being validated by a resolver which does not have the - old zone key cached. If the old key is no longer present in the - current zone, this validation fails, marking the data Bogus. - Alternatively, an attempt could be made to validate data which is - signed with a new key against an old key that lives in a local cache, - also resulting in data being marked Bogus. - -4.2.1 Zone-signing Key Rollovers - - For zone-signing key rollovers there are two ways to make sure that - during the rollover data still cached can be verified with the new - key sets or newly generated signatures can be verified with the keys - still in caches. One schema, described in Section 4.2.1.2, uses - double signatures; the other uses key pre-publication - (Section 4.2.1.1). The pros, cons and recommendations are described - in Section 4.2.1.3. - -4.2.1.1 Pre-publish key set Rollover - - This section shows how to perform a ZSK rollover without the need to - sign all the data in a zone twice - the so-called "pre-publish - - - -Kolkman & Gieben Expires September 2, 2005 [Page 13] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - rollover".This method has advantages in the case of a key compromise. - If the old key is compromised, the new key has already been - distributed in the DNS. The zone administrator is then able to - quickly switch to the new key and remove the compromised key from the - zone. Another major advantage is that the zone size does not double, - as is the case with the double signature ZSK rollover. A small - "HOWTO" for this kind of rollover can be found in Appendix B. - - normal pre-roll roll after - - SOA0 SOA1 SOA2 SOA3 - RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) - - DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 DNSKEY11 - RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) - - - normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. - DNSKEY 10 is used to sign all the data of the zone, the zone- - signing key. - pre-roll: DNSKEY 11 is introduced into the key set. Note that no - signatures are generated with this key yet, but this does not - secure against brute force attacks on the public key. The minimum - duration of this pre-roll phase is the time it takes for the data - to propagate to the authoritative servers plus TTL value of the - key set. This equates to two times the Maximum Zone TTL. - roll: At the rollover stage (SOA serial 2) DNSKEY 11 is used to sign - the data in the zone exclusively (i.e. all the signatures from - DNSKEY 10 are removed from the zone). DNSKEY 10 remains published - in the key set. This way data that was loaded into caches from - version 1 of the zone can still be verified with key sets fetched - from version 2 of the zone. - The minimum time that the key set including DNSKEY 10 is to be - published is the time that it takes for zone data from the - previous version of the zone to expire from old caches i.e. the - time it takes for this zone to propagate to all authoritative - servers plus the Maximum Zone TTL value of any of the data in the - previous version of the zone. - after: DNSKEY 10 is removed from the zone. The key set, now only - containing DNSKEY 1 and DNSKEY 11 is resigned with the DNSKEY 1. - - The above scheme can be simplified by always publishing the "future" - key immediately after the rollover. The scheme would look as follows - (we show two rollovers); the future key is introduced in "after" as - DNSKEY 12 and again a newer one, numbered 13, in "2nd after": - - - -Kolkman & Gieben Expires September 2, 2005 [Page 14] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - normal roll after - - SOA0 SOA2 SOA3 - RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) - - DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 DNSKEY11 DNSKEY12 - RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) - RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) - - - 2nd roll 2nd after - - SOA4 SOA5 - RRSIG12(SOA4) RRSIG12(SOA5) - - DNSKEY1 DNSKEY1 - DNSKEY11 DNSKEY12 - DNSKEY12 DNSKEY13 - RRSIG1(DNSKEY) RRSIG1(DNSKEY) - RRSIG12(DNSKEY) RRSIG12(DNSKEY) - - - Note that the key introduced after the rollover is not used for - production yet; the private key can thus be stored in a physically - secure manner and does not need to be 'fetched' every time a zone - needs to be signed. - -4.2.1.2 Double Signature Zone-signing Key Rollover - - This section shows how to perform a ZSK key rollover using the double - zone data signature scheme, aptly named "double sig rollover". - - During the rollover stage the new version of the zone file will need - to propagate to all authoritative servers and the data that exists in - (distant) caches will need to expire, requiring at least the maximum - Zone TTL. - - - - - - - - - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 15] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - normal roll after - - SOA0 SOA1 SOA2 - RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) - RRSIG11(SOA1) - - DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 - RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) - RRSIG11(DNSKEY) - - normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. - DNSKEY 10 is used to sign all the data of the zone, the zone- - signing key. - roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced - into the key set and all the data in the zone is signed with - DNSKEY 10 and DNSKEY 11. The rollover period will need to exist - until all data from version 0 of the zone has expired from remote - caches. This will take at least the maximum Zone TTL of version 0 - of the zone. - after: DNSKEY 10 is removed from the zone. All the signatures from - DNSKEY 10 are removed from the zone. The key set, now only - containing DNSKEY 11, is resigned with DNSKEY 1. - - At every instance, RRSIGs from the previous version of the zone can - be verified with the DNSKEY RRset from the current version and the - other way around. The data from the current version can be verified - with the data from the previous version of the zone. The duration of - the rollover phase and the period between rollovers should be at - least the "Maximum Zone TTL". - - Making sure that the rollover phase lasts until the signature - expiration time of the data in version 0 of the zone is recommended. - This way all caches are cleared of the old signatures. However, this - date could be considerably longer than the Maximum Zone TTL, making - the rollover a lengthy procedure. - - Note that in this example we assumed that the zone was not modified - during the rollover. New data can be introduced in the zone as long - as it is signed with both keys. - -4.2.1.3 Pros and Cons of the Schemes - - - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 16] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - Pre-publish-key set rollover: This rollover does not involve signing - the zone data twice. Instead, before the actual rollover, the new - key is published in the key set and thus available for - cryptanalysis attacks. A small disadvantage is that this process - requires four steps. Also the pre-publish scheme involves more - parental work when used for KSK rollovers as explained in - Section 4.2. - Double signature rollover: The drawback of this signing scheme is - that during the rollover the number of signatures in your zone - doubles, this may be prohibitive if you have very big zones. An - advantage is that it only requires three steps. - -4.2.2 Key-signing Key Rollovers - - For the rollover of a key-signing key the same considerations as for - the rollover of a zone-signing key apply. However we can use a - double signature scheme to guarantee that old data (only the apex key - set) in caches can be verified with a new key set and vice versa. - - Since only the key set is signed with a KSK, zone size considerations - do not apply. - - - normal roll after - - SOA0 SOA1 SOA2 - RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) - - DNSKEY1 DNSKEY1 DNSKEY2 - DNSKEY2 - DNSKEY10 DNSKEY10 DNSKEY10 - RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) - RRSIG2 (DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) - - normal: Version 0 of the zone. The parental DS points to DNSKEY1. - Before the rollover starts the child will have to verify what the - TTL is of the DS RR that points to DNSKEY1 - it is needed during - the rollover and we refer to the value as TTL_DS. - roll: During the rollover phase the zone administrator generates a - second KSK, DNSKEY2. The key is provided to the parent and the - child will have to wait until a new DS RR has been generated that - points to DNSKEY2. After that DS RR has been published on all - servers authoritative for the parent's zone, the zone - administrator has to wait at least TTL_DS to make sure that the - old DS RR has expired from caches. - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 17] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - after: DNSKEY1 has been removed. - - The scenario above puts the responsibility for maintaining a valid - chain of trust with the child. It also is based on the premises that - the parent only has one DS RR (per algorithm) per zone. An - alternative mechanism has been considered. Using an established - trust relation, the interaction can be performed in-band, and the - removal of the keys by the child can possibly be signaled by the - parent. In this mechanism there are periods where there are two DS - RRs at the parent. Since at the moment of writing the protocol for - this interaction has not been developed further discussion is out of - scope for this document. - -4.2.3 Difference Between ZSK and KSK Rollovers - - Note that KSK rollovers and ZSK rollovers are different. A zone-key - rollover can be handled in two different ways: pre-publish (Section - Section 4.2.1.1) and double signature (Section Section 4.2.1.2). - - As the KSK is used to validate the key set and because the KSK is not - changed during a ZSK rollover, a cache is able to validate the new - key set of the zone. The pre-publish method would work for a KSK - rollover. The record that are to be pre-published are the parental - DS RRs. - - The pre-publish method has some drawbacks. We first describe the - rollover scheme and then indicate these drawbacks. - - normal pre-roll roll after - Parent: - SOA0 SOA1 SOA2 SOA3 - RRSIGpar(SOA0) RRSIGpar(SOA1) RRSIGpar(SOA2) RRSIGpar(SOA3) - DS1 DS1 DS1 DS2 - DS2 DS2 - RRSIGpar(DS) RRSIGpar(DS) RRSIGpar(DS) RRSIGpar(DS) - - - - Child: - SOA0 SOA0 SOA1 SOA1 - RRSIG10(SOA0) RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA1) - - DNSKEY1 DNSKEY1 DNSKEY2 DNSKEY2 - - DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY10 - RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) RRSIG2 (DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 18] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - When the child zone wants to roll it notifies the parent during the - pre-roll phase and submits the new key to the parent. The parent - publishes DS1 and DS2, pointing to DNSKEY1 and DNSKEY2 respectively. - During the rollover, which can take place as soon as the new DS set - propagated through the DNS, the child replaces DNSKEY1 with DNSKEY2. - Immediately after that it can notify the parent that the old DS - record can be deleted. - - The drawbacks of these scheme are that during the pre-roll phase the - parent cannot verify the match between the DS RR and DNSKEY2 using - the DNS. Besides, we introduce a "security lame" DS record - Section 4.4.3. Finally the child-parent interaction consists of two - steps. The "double signature" method only needs one interaction. - -4.2.4 Automated Key Rollovers - - As keys must be renewed periodically, there is some motivation to - automate the rollover process. Consider that: - - o ZSK rollovers are easy to automate as only the local zone is - involved. - o A KSK rollover needs interaction between the parent and child. - Data exchange is needed to provide the new keys to the parent, - consequently, this data must be authenticated and integrity must - be guaranteed in order to avoid attacks on the rollover. - o All time and TTL considerations presented in Section 4.2 apply to - an automated rollover. - -4.3 Planning for Emergency Key Rollover - - This section deals with preparation for a possible key compromise. - Our advice is to have a documented procedure ready for when a key - compromise is suspected or confirmed. - - When the private material of one of your keys is compromised it can - be used for as long as a valid authentication chain exists. An - authentication chain remains intact for: - o as long as a signature over the compromised key in the - authentication chain is valid, - o as long as a parental DS RR (and signature) points to the - compromised key, - o as long as the key is anchored in a resolver and is used as a - starting point for validation. (This is generally the hardest to - update.) - - While an authentication chain to your compromised key exists, your - name-space is vulnerable to abuse by anyone who has obtained - illegitimate possession of the key.Zone operators have to make a - - - -Kolkman & Gieben Expires September 2, 2005 [Page 19] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - trade off if the abuse of the compromised key is worse than having - data in caches that cannot be validated. If the zone operator - chooses to break the authentication chain to the compromised key, - data in caches signed with this key cannot be validated. However, if - the zone administrator chooses to take the path of a regular roll- - over, the malicious key holder can spoof data so that it appears to - be valid. Note that this kind of attack is more likely to occur in a - localized part of the network topology i.e. downstream from where the - spoof takes place. - - -4.3.1 KSK Compromise - - When the KSK has been compromised the parent must be notified as soon - as possible using secure means. The key set of the zone should be - resigned as soon as possible. Care must be taken to not break the - authentication chain. The local zone can only be resigned with the - new KSK after the parent's zone has created and reloaded its zone - with the DS created from the new KSK. Before this update takes place - it would be best to drop the security status of a zone all together: - the parent removes the DS of the child at the next zone update. - After that the child can be made secure again. - - An additional danger of a key compromise is that the compromised key - can be used to facilitate a legitimate DNSKEY/DS and/or nameserver - rollover at the parent. When that happens the domain can be in - dispute. An authenticated out of band and secure notify mechanism to - contact a parent is needed in this case. - -4.3.2 ZSK Compromise - - Primarily because there is no parental interaction required when a - ZSK is compromised, the situation is less severe than with with a KSK - compromise. The zone must still be resigned with a new ZSK as soon - as possible. As this is a local operation and requires no - communication between the parent and child this can be achieved - fairly quickly. However, one has to take into account that just as - with a normal rollover the immediate disappearance from the old - compromised key may lead to verification problems. The pre- - publication scheme as discussed above minimizes such problems. - -4.3.3 Compromises of Keys Anchored in Resolvers - - A key can also be pre-configured in resolvers. For instance, if - DNSSEC is successfully deployed the root key may be pre-configured in - most security aware resolvers. - - If trust-anchor keys are compromised, the resolvers using these keys - - - -Kolkman & Gieben Expires September 2, 2005 [Page 20] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - should be notified of this fact. Zone administrators may consider - setting up a mailing list to communicate the fact that a SEP key is - about to be rolled over. This communication will of course need to - be authenticated e.g. by using digital signatures. - - End-users faced with the task of updating an anchored key should - always validate the new key. New keys should be authenticated out of - the DNS, for example, looking them up on an SSL secured announcement - website. - -4.4 Parental Policies - -4.4.1 Initial Key Exchanges and Parental Policies Considerations - - The initial key exchange is always subject to the policies set by the - parent (or its registry). When designing a key exchange policy one - should take into account that the authentication and authorization - mechanisms used during a key exchange should be as strong as the - authentication and authorization mechanisms used for the exchange of - delegation information between parent and child. I.e. there is no - implicit need in DNSSEC to make the authentication process stronger - than it was in DNS. - - Using the DNS itself as the source for the actual DNSKEY material, - with an off-band check on the validity of the DNSKEY, has the benefit - that it reduces the chances of user error. A parental DNSKEY - download tool can make use of the SEP bit [1] to select the proper - key from a DNSSEC key set; thereby reducing the chance that the wrong - DNSKEY is sent. It can validate the self-signature over a key; - thereby verifying the ownership of the private key material. - Fetching the DNSKEY from the DNS ensures that the chain of trust - remains intact once the parent publishes the DS RR indicating the - child is secure. - - Note: the off-band verification is still needed when the key-material - is fetched via the DNS. The parent can never be sure whether the - DNSKEY RRs have been spoofed or not. - -4.4.2 Storing Keys or Hashes? - - When designing a registry system one should consider which of the - DNSKEYs and/or the corresponding DSs to store. Since a child zone - might wish to have a DS published using a message digest algorithm - not yet understood by the registry, the registry can't count on being - able to generate the DS record from a raw DNSKEY. Thus, we recommend - that registry system at least support storing DS records. - - It may also be useful to store DNSKEYs, since having them may help - - - -Kolkman & Gieben Expires September 2, 2005 [Page 21] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - during troubleshooting and, so long as the child's chosen message - digest is supported, the overhead of generating DS records from them - is minimal. Having an out-of-band mechanism, such as a Whois - database, to find out which keys are used to generate DS Resource - Records for specific owners and/or zones may also help with - troubleshooting. - - The storage considerations also relate the design of the customer - interface and the method by which data is transfered between - registrant and registry; Will the child zone owner be able to upload - DS RRs with unknown hash algorithms or does the interface only allows - DNSKEYs? In the registry-registrar model one can use the DNSSEC EPP - protocol extensions [9] which allows transfer of DS RRs and - optionally DNSKEY RRs. - -4.4.3 Security Lameness - - Security Lameness is defined as what happens when a parent has a DS - RR pointing to a non-existing DNSKEY RR. During key exchange a - parent should make sure that the child's key is actually configured - in the DNS before publishing a DS RR in its zone. Failure to do so - could cause the child's zone being marked as Bogus. - - Child zones should be very careful removing DNSKEY material, - specifically SEP keys, for which a DS RR exists. - - Once a zone is "security lame", a fix (e.g. removing a DS RR) will - take time to propagate through the DNS. - -4.4.4 DS Signature Validity Period - - Since the DS can be replayed as long as it has a valid signature, a - short signature validity period over the DS minimizes the time a - child is vulnerable in the case of a compromise of the child's - KSK(s). A signature validity period that is too short introduces the - possibility that a zone is marked Bogus in case of a configuration - error in the signer. There may not be enough time to fix the - problems before signatures expire. Something as mundane as operator - unavailability during weekends shows the need for DS signature - validity periods longer than 2 days. We recommend the minimum for a - DS signature validity period of a few days. - - The maximum signature validity period of the DS record depends on how - long child zones are willing to be vulnerable after a key compromise. - Other considerations, such as how often the zone is (re)signed can - also be taken into account. - - We consider a signature validity period of around one week to be a - - - -Kolkman & Gieben Expires September 2, 2005 [Page 22] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - good compromise between the operational constraints of the parent and - minimizing damage for the child. - - In addition to the signature validity period, which sets a lower - bound on the amount of times the zone owner will need to sign the - zone data and which sets an upper bound to the time a child is - vulnerable after key compromise, there is the TTL value on the DS - RRs. By lowering the TTL, the authoritative servers will see more - queries, on the other hand a low TTL increases the speed with which - new DS RRs propagate through the DNS. As argued in Section 4.1.1, - the TTL should be a fraction of the signature validity period. - -5. Security Considerations - - DNSSEC adds data integrity to the DNS. This document tries to assess - the operational considerations to maintain a stable and secure DNSSEC - service. Not taking into account the 'data propagation' properties - in the DNS will cause validation failures and may make secured zones - unavailable to security aware resolvers. - -6. Acknowledgments - - Most of the ideas in this draft were the result of collective efforts - during workshops, discussions and try outs. - - At the risk of forgetting individuals who were the original - contributors of the ideas we would like to acknowledge people who - were actively involved in the compilation of this document. In - random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael - Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette - Olivier Courtay, Sam Weiler, Jelte Jansen and Niall O'Reilly. - - Some material in this document has been shamelessly copied from - RFC2541 [7] by Donald Eastlake. - - Mike StJohns designed the key exchange between parent and child - mentioned in the last paragraph of Section 4.2.2 - - Section 4.2.4 was supplied by G. Guette and O. Courtay. - - Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of - the spelling and style issues. - - Kolkman and Gieben take the blame for introducing all miscakes(SIC). - -7. References - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 23] - -Internet-Draft DNSSEC Operational Practices March 2005 - - -7.1 Normative References - - [1] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - -7.2 Informative References - - [3] Eastlake, D., Crocker, S., and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1994. - - [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [5] Eastlake, D., "Secure Domain Name System Dynamic Update", - RFC 2137, April 1997. - - [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - - [7] Eastlake, D., "DNS Security Operational Considerations", - RFC 2541, March 1999. - - [8] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", - RFC 3658, December 2003. - - [9] Hollenbeck, S., "Domain Name System (DNS) Security Extensions - Mapping for the Extensible Provisioning Protocol (EPP)", - draft-hollenbeck-epp-secdns-07 (work in progress), March 2005. - - [10] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key - Sizes", The Journal of Cryptology 14 (255-293), 2001. - - [11] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and - Source Code in C", 1996. - - - - - - - - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 24] - -Internet-Draft DNSSEC Operational Practices March 2005 - - -Authors' Addresses - - Olaf M. Kolkman - RIPE NCC - Singel 256 - Amsterdam 1016 AB - The Netherlands - - Phone: +31 20 535 4444 - Email: olaf@ripe.net - URI: http://www.ripe.net/ - - - Miek Gieben - NLnet Labs - Kruislaan 419 - Amsterdam 1098 VA - The Netherlands - - Email: miek@nlnetlabs.nl - URI: http://www.nlnetlabs.nl - -Appendix A. Terminology - - In this document there is some jargon used that is defined in other - documents. In most cases we have not copied the text from the - documents defining the terms but given a more elaborate explanation - of the meaning. Note that these explanations should not be seen as - authoritative. - - Anchored Key: A DNSKEY configured in resolvers around the globe. - This key is hard to update, hence the term anchored. - Bogus: Also see Section 5 of [2]. An RRset in DNSSEC is marked - "Bogus" when a signature of a RRset does not validate against a - DNSKEY. - Key-Signing Key or KSK: A Key-Signing Key (KSK) is a key that is used - exclusively for signing the apex key set. The fact that a key is - a KSK is only relevant to the signing tool. - Private and Public Keys: DNSSEC secures the DNS through the use of - public key cryptography. Public key cryptography is based on the - existence of two keys, a public key and a private key. The public - keys are published in the DNS by use of the DNSKEY Resource Record - (DNSKEY RR). Private keys should remain private. - Key Rollover: A key rollover (also called key supercession in some - environments) is the act of replacing one key pair by another at - the end of a key effectivity period. - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 25] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - Secure Entry Point key or SEP Key: A KSK that has a parental DS - record pointing to it. Note: this is not enforced in the - protocol. A SEP Key with no parental DS is security lame. - Singing the Zone File: The term used for the event where an - administrator joyfully signs its zone file while producing melodic - sound patterns. - Signer: The system that has access to the private key material and - signs the Resource Record sets in a zone. A signer may be - configured to sign only parts of the zone e.g. only those RRsets - for which existing signatures are about to expire. - Zone-Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is - used for signing all data in a zone. The fact that a key is a ZSK - is only relevant to the signing tool. - Zone Administrator: The 'role' that is responsible for signing a zone - and publishing it on the primary authoritative server. - -Appendix B. Zone-signing Key Rollover Howto - - Using the pre-published signature scheme and the most conservative - method to assure oneself that data does not live in caches here - follows the "HOWTO". - Step 0: The preparation: Create two keys and publish both in your key - set. Mark one of the keys as "active" and the other as - "published". Use the "active" key for signing your zone data. - Store the private part of the "published" key, preferably off- - line. - The protocol does not provide for attributes to mark a key as - active or published. This is something you have to do on your - own, through the use of a notebook or key management tool. - Step 1: Determine expiration: At the beginning of the rollover make a - note of the highest expiration time of signatures in your zone - file created with the current key marked as "active". - Wait until the expiration time marked in Step 1 has passed - Step 2: Then start using the key that was marked as "published" to - sign your data i.e. mark it as "active". Stop using the key that - was marked as "active", mark it as "rolled". - Step 3: It is safe to engage in a new rollover (Step 1) after at - least one "signature validity period". - -Appendix C. Typographic Conventions - - The following typographic conventions are used in this document: - Key notation: A key is denoted by KEYx, where x is a number, x could - be thought of as the key id. - - - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 26] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - RRset notations: RRs are only denoted by the type. All other - information - owner, class, rdata and TTL - is left out. Thus: - "example.com 3600 IN A 192.168.1.1" is reduced to "A". RRsets are - a list of RRs. A example of this would be: "A1,A2", specifying - the RRset containing two "A" records. This could again be - abbreviated to just "A". - Signature notation: Signatures are denoted as RRSIGx(RRset), which - means that RRset is signed with DNSKEYx. - Zone representation: Using the above notation we have simplified the - representation of a signed zone by leaving out all unnecessary - details such as the names and by representing all data by "SOAx" - SOA representation: SOA's are represented as SOAx, where x is the - serial number. - Using this notation the following zone: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 27] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - example.net. 600 IN SOA ns.example.net. bert.example.net. ( - 10 ; serial - 450 ; refresh (7 minutes 30 seconds) - 600 ; retry (10 minutes) - 345600 ; expire (4 days) - 300 ; minimum (5 minutes) - ) - 600 RRSIG SOA 5 2 600 20130522213204 ( - 20130422213204 14 example.net. - cmL62SI6iAX46xGNQAdQ... ) - 600 NS a.iana-servers.net. - 600 NS b.iana-servers.net. - 600 RRSIG NS 5 2 600 20130507213204 ( - 20130407213204 14 example.net. - SO5epiJei19AjXoUpFnQ ... ) - 3600 DNSKEY 256 3 5 ( - EtRB9MP5/AvOuVO0I8XDxy0... - ) ; key id = 14 - 3600 DNSKEY 256 3 5 ( - gsPW/Yy19GzYIY+Gnr8HABU... - ) ; key id = 15 - 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( - 20130422213204 14 example.net. - J4zCe8QX4tXVGjV4e1r9... ) - 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( - 20130422213204 15 example.net. - keVDCOpsSeDReyV6O... ) - 600 RRSIG NSEC 5 2 600 20130507213204 ( - 20130407213204 14 example.net. - obj3HEp1GjnmhRjX... ) - a.example.net. 600 IN TXT "A label" - 600 RRSIG TXT 5 3 600 20130507213204 ( - 20130407213204 14 example.net. - IkDMlRdYLmXH7QJnuF3v... ) - 600 NSEC b.example.com. TXT RRSIG NSEC - 600 RRSIG NSEC 5 3 600 20130507213204 ( - 20130407213204 14 example.net. - bZMjoZ3bHjnEz0nIsPMM... ) - - ... - - - is reduced to the following representation: - - - - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 28] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - SOA10 - RRSIG14(SOA10) - - DNSKEY14 - DNSKEY15 - - RRSIG14(KEY) - RRSIG15(KEY) - - The rest of the zone data has the same signature as the SOA record, - i.e a RRSIG created with DNSKEY 14. - -Appendix D. Document Details and Changes - - This section is to be removed by the RFC editor if and when the - document is published. - - $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14 - 2005/03/21 15:51:41 dnssec Exp $ - -D.1 draft-ietf-dnsop-dnssec-operational-practices-00 - - Submission as working group document. This document is a modified - and updated version of draft-kolkman-dnssec-operational-practices-00. - -D.2 draft-ietf-dnsop-dnssec-operational-practices-01 - - changed the definition of "Bogus" to reflect the one in the protocol - draft. - - Bad to Bogus - - Style and spelling corrections - - KSK - SEP mapping made explicit. - - Updates from Sam Weiler added - -D.3 draft-ietf-dnsop-dnssec-operational-practices-02 - - Style and errors corrected. - - Added Automatic rollover requirements from I-D.ietf-dnsop-key- - rollover-requirements. - -D.4 draft-ietf-dnsop-dnssec-operational-practices-03 - - Added the definition of Key effectivity period and used that term - - - -Kolkman & Gieben Expires September 2, 2005 [Page 29] - -Internet-Draft DNSSEC Operational Practices March 2005 - - - instead of Key validity period. - - Modified the order of the sections, based on a suggestion by Rip - Loomis. - - Included parts from RFC2541 [7]. Most of its ground was already - covered. This document obsoletes RFC2541 [7]. Section 3.1.2 - deserves some review as it in contrast to RFC2541 does _not_ give - recomendations about root-zone keys. - - added a paragraph to Section 4.4.4 - -D.5 draft-ietf-dnsop-dnssec-operational-practices-04 - - Somewhat more details added about the pre-publish KSK rollover. Also - moved that subsection down a bit. - - Editorial and content nits that came in during wg last call were - fixed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 30] - -Internet-Draft DNSSEC Operational Practices March 2005 - - -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 (2005). 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. - - - - -Kolkman & Gieben Expires September 2, 2005 [Page 31] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt deleted file mode 100644 index 242aa9e..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt +++ /dev/null @@ -1,616 +0,0 @@ - - -Network Working Group S. Woolf -Internet-Draft Internet Systems Consortium, Inc. -Expires: September 14, 2005 D. Conrad - Nominum, Inc. - March 13, 2005 - - - Identifying an Authoritative Name Server - draft-ietf-dnsop-serverid-04 - -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 September 14, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - - - -Woolf & Conrad Expires September 14, 2005 [Page 1] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - - query would be useful, particularly as a diagnostic aid. Existing ad - hoc mechanisms for addressing this concern are not adequate. This - document attempts to describe the common ad hoc solution to this - problem, including its advantages and disadvantages, and to - characterize an improved mechanism. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 14, 2005 [Page 2] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -1. Introduction - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid. - - Unfortunately, existing ad-hoc mechanisms for providing such - identification have some shortcomings, not the least of which is the - lack of prior analysis of exactly how such a mechanism should be - designed and deployed. This document describes the existing - convention used in one widely deployed implementation of the DNS - protocol and discusses requirements for an improved solution to the - problem. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 14, 2005 [Page 3] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -2. Rationale - - Identifying which name server is responding to queries is often - useful, particularly in attempting to diagnose name server - difficulties. However, relying on the IP address of the name server - has become more problematic due the deployment of various load - balancing solutions, including the use of shared unicast addresses as - documented in [RFC3258]. - - An unfortunate side effect of these load balancing solutions, and - some changes in management practices as the public Internet has - evolved, is that traditional methods of determining which server is - responding can be unreliable. Specifically, non-DNS methods such as - ICMP ping, TCP connections, or non-DNS UDP packets (such as those - generated by tools such as "traceroute"), etc., can end up going to a - different server than that which receives the DNS queries. - - There is a well-known and frequently-used technique for determining - an identity for a nameserver more specific than the - possibly-non-unique "server that answered my query". The widespread - use of the existing convention suggests a need for a documented, - interoperable means of querying the identity of a nameserver that may - be part of an anycast or load-balancing cluster. At the same time, - however, it also has some drawbacks that argue against standardizing - it as it's been practiced so far. - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 14, 2005 [Page 4] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -3. Existing Conventions - - Recent versions of the commonly deployed Berkeley Internet Name - Domain implementation of the DNS protocol suite from the Internet - Software Consortium [BIND] support a way of identifying a particular - server via the use of a standard, if somewhat unusual, DNS query. - Specifically, a query to a late model BIND server for a TXT resource - record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will - return a string that can be configured by the name server - administrator to provide a unique identifier for the responding - server (defaulting to the value of a gethostname() call). This - mechanism, which is an extension of the BIND convention of using - CHAOS class TXT RR queries to sub-domains of the "BIND." domain for - version information, has been copied by several name server vendors. - - For reference, the other well-known name used by recent versions of - BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A - query for a TXT RR for this name will return an administratively - defined string which defaults to the version of the server - responding. This is, however, not generally implemented by other - vendors. - -3.1 Advantages - - There are several valuable attributes to this mechanism, which - account for its usefulness. - 1. The "hostname.bind" query response mechanism is within the DNS - protocol itself. An identification mechanism that relies on the - DNS protocol is more likely to be successful (although not - guaranteed) in going to the same machine as a "normal" DNS query. - 2. Since the identity information is requested and returned within - the DNS protocol, it doesn't require allowing any other query - mechanism to the server, such as holes in firewalls for - otherwise-unallowed ICMP Echo requests. Thus it does not require - any special exceptions to site security policy. - 3. It is simple to configure. An administrator can easily turn on - this feature and control the results of the relevant query. - 4. It allows the administrator complete control of what information - is given out in the response, minimizing passive leakage of - implementation or configuration details. Such details are often - considered sensitive by infrastructure operators. - -3.2 Disadvantages - - At the same time, there are some forbidding drawbacks to the - VERSION.BIND mechanism that argue against standardizing it as it - currently operates. - - - - -Woolf & Conrad Expires September 14, 2005 [Page 5] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - - 1. It requires an additional query to correlate between the answer - to a DNS query under normal conditions and the supposed identity - of the server receiving the query. There are a number of - situations in which this simply isn't reliable. - 2. It reserves an entire class in the DNS (CHAOS) for what amounts - to one zone. While CHAOS class is defined in [RFC1034] and - [RFC1035], it's not clear that supporting it solely for this - purpose is a good use of the namespace or of implementation - effort. - 3. It is implementation specific. BIND is one DNS implementation. - At the time of this writing, it is probably the most prevalent - for authoritative servers. This does not justify standardizing - on its ad hoc solution to a problem shared across many operators - and implementors. - - The first of the listed disadvantages is technically the most - serious. It argues for an attempt to design a good answer to the - problem that "I need to know what nameserver is answering my - queries", not simply a convenient one. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 14, 2005 [Page 6] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -4. Characteristics of an Implementation Neutral Convention - - The discussion above of advantages and disadvantages to the - HOSTNAME.BIND mechanism suggest some requirements for a better - solution to the server identification problem. These are summarized - here as guidelines for any effort to provide appropriate protocol - extensions: - 1. The mechanism adopted MUST be in-band for the DNS protocol. That - is, it needs to allow the query for the server's identifying - information to be part of a normal, operational query. It SHOULD - also permit a separate, dedicated query for the server's - identifying information. - 2. The new mechanism SHOULD not require dedicated namespaces or - other reserved values outside of the existing protocol mechanisms - for these, i.e. the OPT pseudo-RR. In particular, it should not - propagate the existing drawback of requiring support for a CLASS - and top level domain in the authoritative server (or the querying - tool) to be useful. - 3. Support for the identification functionality SHOULD be easy to - implement and easy to enable. It MUST be easy to disable and - SHOULD lend itself to access controls on who can query for it. - 4. It should be possible to return a unique identifier for a server - without requiring the exposure of information that may be - non-public and considered sensitive by the operator, such as a - hostname or unicast IP address maintained for administrative - purposes. - 5. The identification mechanism SHOULD NOT be - implementation-specific. - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 14, 2005 [Page 7] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -5. IANA Considerations - - This document proposes no specific IANA action. Protocol extensions, - if any, to meet the requirements described are out of scope for this - document. Should such extensions be specified and adopted by normal - IETF process, the specification will include appropriate guidance to - IANA. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 14, 2005 [Page 8] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -6. Security Considerations - - Providing identifying information as to which server is responding to - a particular query from a particular location in the Internet can be - seen as information leakage and thus a security risk. This motivates - the suggestion above that a new mechanism for server identification - allow the administrator to disable the functionality altogether or - partially restrict availability of the data. It also suggests that - the serverid data should not be readily correlated with a hostname or - unicast IP address that may be considered private to the nameserver - operator's management infrastructure. - - Propagation of protocol or service meta-data can sometimes expose the - application to denial of service or other attack. As DNS is a - critically important infrastructure service for the production - Internet, extra care needs to be taken against this risk for - designers, implementors, and operators of a new mechanism for server - identification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 14, 2005 [Page 9] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -7. Acknowledgements - - The technique for host identification documented here was initially - implemented by Paul Vixie of the Internet Software Consortium in the - Berkeley Internet Name Daemon package. Comments and questions on - earlier drafts were provided by Bob Halley, Brian Wellington, Andreas - Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the - ICANN Root Server System Advisory Committee. The newest version - takes a significantly different direction from previous versions, - owing to discussion among contributors to the DNSOP working group and - others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam - Weiler, and Rob Austein. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 14, 2005 [Page 10] - -Internet-Draft Identifying an Authoritative Name Server March 2005 - - -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 (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Woolf & Conrad Expires September 14, 2005 [Page 11] - - |
