d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove from the vendor branch files that are no longer

Browse Source 
present in BIND 9.4.1.
This commit is contained in:
Doug Barton 2007-06-02 23:29:48 +00:00
parent 141cfa5029
commit d6a1012ea9
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/vendor/bind9/dist/; revision=170225
12 changed files with 0 additions and 10066 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

252
contrib/bind9/bin/named/aclconf.c
View File

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

72
contrib/bind9/bin/named/include/named/aclconf.h
View File

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

562
contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt
View File

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

560
contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt
View File

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

754
contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-06.txt
View File

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

2072
contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt
View File

File diff suppressed because it is too large Load Diff

730
contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt
View File

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

580
contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt
View File

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

956
contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt
View File

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

1176
contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt
View File

File diff suppressed because it is too large Load Diff

1736
contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-04.txt
View File

File diff suppressed because it is too large Load Diff

616
contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-04.txt
View File

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