+++ /dev/null
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
--- /dev/null
+
+
+
+
+DNSEXT M. Stapp
+Internet-Draft Cisco Systems, Inc.
+Expires: September 1, 2006 T. Lemon
+ Nominum, Inc.
+ A. Gustafsson
+ Araneus Information Systems Oy
+ February 28, 2006
+
+
+ A DNS RR for Encoding DHCP Information (DHCID RR)
+ <draft-ietf-dnsext-dhcid-rr-12.txt>
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on September 1, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ It is possible for DHCP clients to attempt to update the same DNS
+ FQDN or attempt to update a DNS FQDN that has been added to the DNS
+ for another purpose 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
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 1]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+ Conflicts" [1] 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 . . . . . . . . . . . . . . . . . . . . 3
+ 3.2. DHCID Presentation Format . . . . . . . . . . . . . . . . 4
+ 3.3. The DHCID RR Identifier Type Codes . . . . . . . . . . . . 4
+ 3.4. The DHCID RR Digest Type Code . . . . . . . . . . . . . . 4
+ 3.5. Computation of the RDATA . . . . . . . . . . . . . . . . . 5
+ 3.5.1. Using the Client's DUID . . . . . . . . . . . . . . . 5
+ 3.5.2. Using the Client Identifier Option . . . . . . . . . . 5
+ 3.5.3. Using the Client's htype and chaddr . . . . . . . . . 6
+ 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.6.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 7
+ 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 7
+ 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
+ Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 2]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+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 [6] [10] 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 or a DHCP client attempts to use a name added for another
+ purpose. 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 obscure potentially sensitive client identifying
+ information, the data stored is the result of a one-way SHA-256 hash
+ computation. The hash includes information from the DHCP client's
+ 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.
+
+
+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.
+
+3.1. DHCID RDATA format
+
+ The RDATA section of a DHCID RR in transmission contains RDLENGTH
+ octets 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
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 3]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+ 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 2-octet identifier type, in network byte order,
+ followed by a 1-octet digest type, followed by one or more octets
+ representing the actual identifier:
+
+ < 2 octets > Identifier type code
+ < 1 octet > Digest type code
+ < n octets > Digest (length depends on digest type)
+
+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 3548 [7]. 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 Identifier Type Codes
+
+ The DHCID RR Identifier Type Code specifies what data from the DHCP
+ client's request was used as input into the hash function. The
+ identifier type codes are defined in a registry maintained by IANA,
+ as specified in Section 7. The initial list of assigned values for
+ the identifier type code is:
+
+ 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6].
+ 0x0001 = The data octets (i.e., the Type and Client-Identifier
+ fields) from a DHCPv4 client's Client Identifier option [9].
+ 0x0002 = The client's DUID (i.e., the data octets 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. The DHCID RR Digest Type Code
+
+ The DHCID RR Digest Type Code is an identifier for the digest
+ algorithm used. The digest is calculated over an identifier and the
+ canonical FQDN as described in the next section.
+
+ The digest type codes are defined in a registry maintained by IANA,
+ as specified in Section 7. The initial list of assigned values for
+ the digest type codes is: value 0 is reserved and value 1 is SHA-256.
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 4]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+ Reserving other types requires IETF standards action. Defining new
+ values will also require IETF standards action to document how DNS
+ updaters are to deal with multiple digest types.
+
+3.5. Computation of the RDATA
+
+ The DHCID RDATA is formed by concatenating the 2-octet identifier
+ type code with variable-length data.
+
+ The RDATA for all type codes other than 0xffff, which is reserved for
+ future expansion, is formed by concatenating the 2-octet identifier
+ type code, the 1-octet digest type code, and the digest value (32
+ octets for SHA-256).
+
+ < identifier-type > < digest-type > < digest >
+
+ The input to the digest hash function is defined to be:
+
+ digest = SHA-256(< identifier > < FQDN >)
+
+ The FQDN is represented in the buffer in unambiguous canonical form
+ as described in RFC 4034 [8], section 6.1. The identifier type code
+ and the identifier are related as specified in Section 3.3: the
+ identifier type code describes the source of the identifier.
+
+ A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
+ option is present in the DHCPv4 messages and it is encoded as
+ specified in [12]. Otherwise, the updater uses 0x0001 if a Client
+ Identifier option is present and 0x0000 if not.
+
+ A DHCPv6 updater always uses the 0x0002 type code.
+
+3.5.1. Using the Client's DUID
+
+ When the updater is using the Client's DUID (either from a DHCPv6
+ Client Identifier option or from a portion of the DHCPv4 Client
+ Identifier option encoded as specified in [12]), the first two octets
+ of the DHCID RR MUST be 0x0002, in network byte order. The third
+ octet is the digest type code (1 for SHA-256). The rest of the DHCID
+ RR MUST contain the results of computing the SHA-256 hash across the
+ octets of the DUID followed by the FQDN.
+
+3.5.2. Using the Client Identifier Option
+
+ When the updater is using the DHCPv4 Client Identifier option sent by
+ the client in its DHCPREQUEST message, the first two octets of the
+ DHCID RR MUST be 0x0001, in network byte order. The third octet is
+ the digest type code (1 for SHA-256). The rest of the DHCID RR MUST
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 5]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+ contain the results of computing the SHA-256 hash across the data
+ octets (i.e., the Type and Client-Identifier fields) of the option,
+ followed by the FQDN.
+
+3.5.3. Using the Client's htype and chaddr
+
+ When the updater is using the client's link-layer address as the
+ identifier, the first two octets of the DHCID RDATA MUST be zero.
+ The third octet is the digest type code (1 for SHA-256). To generate
+ the rest of the resource record, the updater computes a one-way hash
+ using the SHA-256 algorithm across a buffer containing the client's
+ network hardware type, link-layer address, and the FQDN data.
+ Specifically, the first octet 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 octets of the
+ 'chaddr' field in the client's DHCPREQUEST message follow, in the
+ same order in which the octets appear in the DHCPREQUEST message.
+ The number of significant octets in the 'chaddr' field is specified
+ in the 'hlen' field of the DHCPREQUEST message. The FQDN data, as
+ specified above, follows.
+
+3.6. Examples
+
+3.6.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
+ octets to zero, the 1-octet digest type to 1 for SHA-256, and
+ performing an SHA-256 hash computation across a buffer containing the
+ Ethernet MAC type octet, 0x01, the six octets of MAC address, and the
+ domain name (represented as specified in Section 3.5).
+
+ client.example.com. A 10.0.0.1
+ client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
+ ytcKD//7es/deY= )
+
+ If the DHCID RR type is not supported, the RDATA would be encoded
+ [13] as:
+
+ \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
+ fffedeb3f75e6 )
+
+3.6.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
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 6]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+ 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 octets to the value 0x0001, the 1-octet digest
+ type to 1 for SHA-256, and performing a SHA-256 hash computation
+ across a buffer containing the seven octets from the client-id option
+ and the FQDN (represented as specified in Section 3.5).
+
+ chi.example.com. A 10.0.12.99
+ chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
+ L3b/NaiUDlW2No= )
+
+ If the DHCID RR type is not supported, the RDATA would be encoded
+ [13] as:
+
+ \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
+ 6a2503956d8da )
+
+3.6.3. Example 3
+
+ A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
+ which included the DHCPv6 client-identifier option data 00:01:00:06:
+ 41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The server
+ updates the name "chi6.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 octets to the
+ value 0x0002, the 1-octet digest type to 1 for SHA-256, and
+ performing a SHA-256 hash computation across a buffer containing the
+ 14 octets from the client-id option and the FQDN (represented as
+ specified in Section 3.5).
+
+ chi6.example.com. AAAA 2000::1234:5678
+ chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
+ OjxfNuVAA2kjEA= )
+
+ If the DHCID RR type is not supported, the RDATA would be encoded
+ [13] as:
+
+ \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
+ b95000da48c40 )
+
+
+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.
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 7]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+ 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
+ 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 obscure the client's identity information,
+ a one-way hash is used. And, 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.
+
+ However, it should be noted that an attacker that has some knowledge,
+ such as of MAC addresses commonly used in DHCP client identification
+ data, may be able to discover the client's DHCP identify by using a
+ brute-force attack. Even without any additional knowledge, the
+ number of unknown bits used in computing the hash is typically only
+ 48 to 80.
+
+ Administrators should be wary of permitting unsecured DNS updates to
+ zones, whether or not they 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
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 8]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+ IANA is requested to allocate a DNS RR type number for the DHCID
+ record type.
+
+ This specification defines a new number-space for the 2-octet
+ identifier 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 identifier
+ type codes are assigned through Standards Action, as defined in RFC
+ 2434 [5].
+
+ This specification defines a new number-space for the 1-octet digest
+ type codes associated with the DHCID RR. IANA is requested to
+ establish a registry of the values for this number-space. Two
+ initial values are assigned in Section 3.4. New DHCID RR digest type
+ codes are assigned through Standards Action, as defined in RFC 2434
+ [5].
+
+
+8. Acknowledgements
+
+ Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
+ Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
+ Volz for their review and suggestions.
+
+
+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-*)", February 2006.
+
+ [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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 9]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+9.2. Informative References
+
+ [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+ [7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+ RFC 3548, July 2003.
+
+ [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [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 Dynamic Host Configuration Protocol Version Four (DHCPv4)",
+ RFC 4361, February 2006.
+
+ [13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+ Types", RFC 3597, September 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 10]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+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
+ Araneus Information Systems Oy
+ Ulappakatu 1
+ 02320 Espoo
+ Finland
+
+ Email: gson@araneus.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 11]
+\f
+Internet-Draft The DHCID RR February 2006
+
+
+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 (2006). 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 September 1, 2006 [Page 12]
+\f
+
projects / thirdparty / bind9.git / commitdiff
