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

bind 源码 最新实现 linux/unix/windows平台

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: [phone]
   Email: [e-mail]


   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 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
   [e-mail].


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]