Network Working Group A. Gustafsson Internet-Draft T. Lemon Expires: January 12, 2001 Nominum, Inc. M. Stapp Cisco Systems, Inc. July 14, 2000 A DNS RR for encoding DHCP information Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract A situation can arise where multiple DHCP clients request the same DNS name from their (possibly distinct) DHCP servers. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[7] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients "owning" them. This memo defines a distinct RR type for use by DHCP servers, the "DHCID" RR. Gustafsson, et. al. Expires January 12, 2001 [Page 1] Internet-Draft A DNS RR for encoding DHCP information July 2000 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . . 3 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6 Gustafsson, et. al. Expires January 12, 2001 [Page 2] Internet-Draft A DNS RR for encoding DHCP information July 2000 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[1]. 2. Introduction A set of procedures to allow DHCP [RFC2131] clients and servers to automatically update the DNS (RFC1034[2], RFC1035[3]) is proposed in Resolution of DNS Name Conflicts[7]. A situation can arise where multiple DHCP clients wish to use the same DNS name. To resolve such conflicts, Resolution of DNS Name Conflicts[7] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients using them. In the interest of clarity, it would be preferable for this DHCP information to use a distinct RR type. This memo defines a distinct RR type for this purpose for use by DHCP clients or servers, the "DHCID" RR. 3. The DHCID RR The DHCP RR is defined with mnemonic DHCID and type code [TBD]. 4. 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. In DNS master files, the RDATA is represented as a hexadecimal string with an optional "0x" or "0X" prefix. Periods (".") may be inserted anywhere after the "0x" for readability. This format is identical to that of the NSAP RR (RFC1706[4]). The number of hexadecimal digits MUST be even. 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 safely perform dynamic DNS updates to the same zone. From the updater's perspective, the DHCID resource record consists of a 16-bit identifier type, followed by one or more bytes representing the actual identifier. There are two possible forms for a DHCID RR - one that is used when the DHCP server is using the client's link-layer address to identify it, and one that is used when the DHCP server is using some DHCP option that the DHCP client sent to identify it. When the link-layer address is used as the Gustafsson, et. al. Expires January 12, 2001 [Page 3] Internet-Draft A DNS RR for encoding DHCP information July 2000 identifier, the first two bytes of the RRDATA are set to 0. When a DHCP option is used as the identifier, the first two bytes of the RRDATA contain the option number, in network byte order. The two bytes 0xffff are reserved. In both cases, the remainder of the RRDATA is the result of performing a one-way hash across the identifier. The details of the method used to generate the data in the RR and the use to which a DHCP client or server may put this association are beyond the scope of this draft, and are discussed in the draft that specifies the DNS update behavior, 'Resolution of DNS Name Conflicts'[7]. This RR MUST NOT be used for any purpose other than that detailed in the DHC document. Althought this RR contains data that is opaque to DNS servers, the data is meaningful to DHCP updaters. Therefore, new data formats may only be defined through actions of the DHC Working Group. 4.1 Example A DHCP server allocating the IPv4 address 10.0.0.1 to a client "client.org.nil" might use the client's link-layer address to identify the client: client.org.nil. A 10.0.0.1 client.org.nil. DHCID 00.00.18.29.11.17.22.0a.ad.c1.88.10.a3.dd.ff.c8.d9.49 A DHCP server allocating the IPv4 address 10.0.12.99 to a client "chi.org.nil" might use the DHCP client identifier option to identify the client: chi.org.nil. A 10.0.12.99 chi.org.nil. DHCID 00.61.92.71.22.da.01.88.dd.3a.11.8c.1c.a0.ff.94.9d.81 5. 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. 6. IANA Considerations The IANA is requested to allocate an RR type number for the DHCP record type. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Gustafsson, et. al. Expires January 12, 2001 [Page 4] Internet-Draft A DNS RR for encoding DHCP information July 2000 [2] Mockapetris, P., "Domain names - Concepts and Facilities", RFC 1034, Nov 1987. [3] Mockapetris, P., "Domain names - Implementation and Specification", RFC 1035, Nov 1987. [4] Manning, B. and R. Colella, "DNS NSAP Resource Records", RFC 1706, Oct 1994. [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar 1997. [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, Mar 1997. [7] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2000. Authors' Addresses Andreas Gustafsson Nominum, Inc. 950 Charter St. Redwood City, CA 94063 USA EMail: gson@nominum.com Ted Lemon Nominum, Inc. 950 Charter St. Redwood City, CA 94063 USA EMail: mellon@nominum.com Mark Stapp Cisco Systems, Inc. 250 Apollo Dr. Chelmsford, MA 01824 USA Phone: 978.244.8498 EMail: mjs@cisco.com Gustafsson, et. al. Expires January 12, 2001 [Page 5] Internet-Draft A DNS RR for encoding DHCP information July 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Gustafsson, et. al. Expires January 12, 2001 [Page 6]