draft-ietf-dnsext-dhcid-rr-06.txt

bind-3.2.

3.5 Examples

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
   that the client desires to use to compute a client identity hash,


Stapp, et. al.            Expires May 2, 2003                   [Page 6]

Internet-Draft                The DHCID RR                 November 2002


   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[10]) 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 RFC2434[11].

8. Acknowledgements

   Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz,
   and Ralph Droms for their review and suggestions.

References

   [1]   Stapp, M., "Resolution of DNS Name Conflicts Among DHCP


Stapp, et. al.            Expires May 2, 2003                   [Page 7]

Internet-Draft                The DHCID RR                 November 2002


         Clients (draft-ietf-dhc-dns-resolution-*)", March 2001.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", RFC 2119, March 1997.

   [3]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         Mar 1997.

   [4]   Mockapetris, P., "Domain names - Concepts and Facilities", RFC
         1034, Nov 1987.

   [5]   Mockapetris, P., "Domain names - Implementation and
         Specification", RFC 1035, Nov 1987.

   [6]   Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
         April 1992.

   [7]   Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [8]   Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
         Extensions", RFC 2132, Mar 1997.

   [9]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
         (draft-ietf-dhc-dhcpv6-*.txt)", November 2002.

   [10]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
         2845, May 2000.

   [11]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", RFC 2434, October 1998.


Authors' Addresses

   Mark Stapp
   Cisco Systems, Inc.
   250 Apollo Dr.
   Chelmsford, MA  01824
   USA

   Phone: [phone]
   EMail: [e-mail]






Stapp, et. al.            Expires May 2, 2003                   [Page 8]

Internet-Draft                The DHCID RR                 November 2002


   Ted Lemon
   Nominum, Inc.
   950 Charter St.
   Redwood City, CA  94063
   USA

   EMail: [e-mail]


   Andreas Gustafsson
   Nominum, Inc.
   950 Charter St.
   Redwood City, CA  94063
   USA

   EMail: [e-mail]



































Stapp, et. al.            Expires May 2, 2003                   [Page 9]

Internet-Draft                The DHCID RR                 November 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002). 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.



















Stapp, et. al.            Expires May 2, 2003                  [Page 10]