draft-ietf-dnsext-dhcid-rr-06.txt   draft-ietf-dnsext-dhcid-rr-07.txt 
DNSEXT Working Group M. Stapp DNSEXT Working Group M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: May 2, 2003 T. Lemon Expires: April 23, 2004 T. Lemon
A. Gustafsson A. Gustafsson
Nominum, Inc. Nominum, Inc.
November 1, 2002 October 24, 2003
A DNS RR for Encoding DHCP Information (DHCID RR) A DNS RR for Encoding DHCP Information (DHCID RR)
<draft-ietf-dnsext-dhcid-rr-06.txt> <draft-ietf-dnsext-dhcid-rr-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2, 2003. This Internet-Draft will expire on April 23, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
It is possible for multiple DHCP clients to attempt to update the 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 same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
the clients themselves perform the DNS updates, conflicts can arise. the clients themselves perform the DNS updates, conflicts can arise.
To resolve such conflicts, "Resolution of DNS Name Conflicts"[1] To resolve such conflicts, "Resolution of DNS Name Conflicts"[1]
proposes storing client identifiers in the DNS to unambiguously proposes storing client identifiers in the DNS to unambiguously
associate domain names with the DHCP clients to which they refer. associate domain names with the DHCP clients to which they refer.
This memo defines a distinct RR type for this purpose for use by This memo defines a distinct RR type for this purpose for use by
skipping to change at page 2, line 23 skipping to change at page 2, line 23
3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . . 5 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . . 5
3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 6 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 6
5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 6 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
References . . . . . . . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . 7
References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119[2]. document are to be interpreted as described in RFC 2119[2].
2. Introduction 2. Introduction
A set of procedures to allow DHCP[3] clients and servers to A set of procedures to allow DHCP[7] clients and servers to
automatically update the DNS (RFC1034[4], RFC1035[5]) is proposed in automatically update the DNS (RFC 1034[3], RFC 1035[4]) is proposed
"Resolution of DNS Name Conflicts"[1]. in "Resolution of DNS Name Conflicts"[1].
Conflicts can arise if multiple DHCP clients wish to use the same Conflicts can arise if multiple DHCP clients wish to use the same
DNS name. To resolve such conflicts, "Resolution of DNS Name DNS name. To resolve such conflicts, "Resolution of DNS Name
Conflicts"[1] proposes storing client identifiers in the DNS to Conflicts"[1] proposes storing client identifiers in the DNS to
unambiguously associate domain names with the DHCP clients using unambiguously associate domain names with the DHCP clients using
them. In the interest of clarity, it is preferable for this DHCP them. In the interest of clarity, it is preferable for this DHCP
information to use a distinct RR type. This memo defines a distinct 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 for this purpose for use by DHCP clients or servers, the "DHCID"
RR. RR.
In order to avoid exposing potentially sensitive identifying In order to avoid exposing potentially sensitive identifying
information, the data stored is the result of a one-way MD5[6] hash information, the data stored is the result of a one-way MD5[5] hash
computation. The hash includes information from the DHCP client's computation. The hash includes information from the DHCP client's
REQUEST message as well as the domain name itself, so that the data 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 stored in the DHCID RR will be dependent on both the client
identification used in the DHCP protocol interaction and the domain identification used in the DHCP protocol interaction and the domain
name. This means that the DHCID RDATA will vary if a single client 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 is associated over time with more than one name. This makes it
difficult to 'track' a client as it is associated with various difficult to 'track' a client as it is associated with various
domain names. domain names.
The MD5 hash algorithm has been shown to be weaker than the SHA-1 The MD5 hash algorithm has been shown to be weaker than the SHA-1
skipping to change at page 4, line 26 skipping to change at page 4, line 26
consists of a 16-bit identifier type, in network byte order, consists of a 16-bit identifier type, in network byte order,
followed by one or more bytes representing the actual identifier: followed by one or more bytes representing the actual identifier:
< 16 bits > DHCP identifier used < 16 bits > DHCP identifier used
< n bytes > MD5 digest < n bytes > MD5 digest
3.2 DHCID Presentation Format 3.2 DHCID Presentation Format
In DNS master files, the RDATA is represented as a single block in In DNS master files, the RDATA is represented as a single block in
base 64 encoding identical to that used for representing binary data base 64 encoding identical to that used for representing binary data
in RFC2535[7]. The data may be divided up into any number of white 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 space separated substrings, down to single base 64 digits, which are
concatenated to form the complete RDATA. These substrings can span concatenated to form the complete RDATA. These substrings can span
lines using the standard parentheses. lines using the standard parentheses.
3.3 The DHCID RR Type Codes 3.3 The DHCID RR Type Codes
The DHCID RR Type Code specifies what data from the DHCP client's 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 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. defined in a registry maintained by IANA, as specified in Section 7.
The initial list of assigned values for the type code is: The initial list of assigned values for the type code is:
skipping to change at page 5, line 20 skipping to change at page 5, line 20
< type > < data > < type > < data >
The RDATA for all type codes other than 0xffff, which is reserved The RDATA for all type codes other than 0xffff, which is reserved
for future expansion, is formed by concatenating the two type bytes 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 and a 16-byte MD5 hash value. The input to the hash function is
defined to be: defined to be:
data = MD5(< identifier > < FQDN >) data = MD5(< identifier > < FQDN >)
The FQDN is represented in the buffer in unambiguous canonical form The FQDN is represented in the buffer in unambiguous canonical form
as described in RFC2535[7], section 8.1. The type code and the 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 identifier are related as specified in Section 3.3: the type code
describes the source of the identifier. describes the source of the identifier.
When the updater is using the client's link-layer address as the 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 identifier, the first two bytes of the DHCID RDATA MUST be zero. To
generate the rest of the resource record, the updater computes a generate the rest of the resource record, the updater computes a
one-way hash using the MD5 algorithm across a buffer containing the one-way hash using the MD5 algorithm across a buffer containing the
client's network hardware type, link-layer address, and the FQDN client's network hardware type, link-layer address, and the FQDN
data. Specifically, the first byte of the buffer contains the data. Specifically, the first byte of the buffer contains the
network hardware type as it appeared in the DHCP 'htype' field of network hardware type as it appeared in the DHCP 'htype' field of
skipping to change at page 7, line 27 skipping to change at page 7, line 27
information about DHCP clients to public scrutiny, a one-way hash is information about DHCP clients to public scrutiny, a one-way hash is
used to obscure all client information. In order to make it used to obscure all client information. In order to make it
difficult to 'track' a client by examining the names associated with difficult to 'track' a client by examining the names associated with
a particular hash value, the FQDN is included in the hash a particular hash value, the FQDN is included in the hash
computation. Thus, the RDATA is dependent on both the DHCP client computation. Thus, the RDATA is dependent on both the DHCP client
identification data and on each FQDN associated with the client. identification data and on each FQDN associated with the client.
Administrators should be wary of permitting unsecured DNS updates to Administrators should be wary of permitting unsecured DNS updates to
zones which are exposed to the global Internet. Both DHCP clients zones which are exposed to the global Internet. Both DHCP clients
and servers SHOULD use some form of update authentication (e.g., and servers SHOULD use some form of update authentication (e.g.,
TSIG[10]) when performing DNS updates. TSIG[11]) when performing DNS updates.
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate an RR type number for the DHCID record IANA is requested to allocate an RR type number for the DHCID record
type. type.
This specification defines a new number-space for the 16-bit 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 codes associated with the DHCID RR. IANA is requested to establish a
registry of the values for this number-space. registry of the values for this number-space.
Three initial values are assigned in Section 3.3, and the value Three initial values are assigned in Section 3.3, and the value
0xFFFF is reserved for future use. New DHCID RR type codes are 0xFFFF is reserved for future use. New DHCID RR type codes are
tentatively assigned after the specification for the associated type tentatively assigned after the specification for the associated type
code, published as an Internet Draft, has received expert review by code, published as an Internet Draft, has received expert review by
a designated expert. The final assignment of DHCID RR type codes is a designated expert. The final assignment of DHCID RR type codes is
through Standards Action, as defined in RFC2434[11]. through Standards Action, as defined in RFC 2434[6].
8. Acknowledgements 8. Acknowledgements
Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz,
and Ralph Droms for their review and suggestions. and Ralph Droms for their review and suggestions.
References Normative References
[1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
Clients (draft-ietf-dhc-dns-resolution-*)", March 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate [1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients
Requirement Levels", RFC 2119, March 1997. (draft-ietf-dhc-dns-resolution-*)", November 2002.
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Mar 1997. Levels", RFC 2119, March 1997.
[4] Mockapetris, P., "Domain names - Concepts and Facilities", RFC [3] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
1034, Nov 1987. 1034, Nov 1987.
[5] Mockapetris, P., "Domain names - Implementation and [4] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, Nov 1987. Specification", RFC 1035, Nov 1987.
[6] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, [5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April
April 1992. 1992.
[7] Eastlake, D., "Domain Name System Security Extensions", RFC [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
Informative References
[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
Mar 1997.
[8] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[8] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Mar 1997. Extensions", RFC 2132, Mar 1997.
[9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
(draft-ietf-dhc-dhcpv6-*.txt)", November 2002. (draft-ietf-dhc-dhcpv6-*.txt)", November 2002.
[10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC "Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000. 2845, May 2000.
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
Authors' Addresses Authors' Addresses
Mark Stapp Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Dr. 1414 Massachusetts Ave.
Chelmsford, MA 01824 Boxborough, MA 01719
USA USA
Phone: 978.244.8498 Phone: 978.936.1535
EMail: mjs@cisco.com EMail: mjs@cisco.com
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
950 Charter St. 950 Charter St.
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
EMail: mellon@nominum.com EMail: mellon@nominum.com
Andreas Gustafsson Andreas Gustafsson
Nominum, Inc. Nominum, Inc.
950 Charter St. 950 Charter St.
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
EMail: gson@nominum.com EMail: gson@nominum.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/