draft-ietf-dhc-dhcp-dns-12.txt

DHCP服务器源码

8.2 Adding PTR RR Entries to DNS

   The DHCP server submits a DNS query which deletes all of the PTR RRs
   associated with the lease IP address, and adds a PTR RR whose data
   is the client's (possibly disambiguated) host name. The server also
   adds a DHCID RR specified in Section 4.3.

8.3 Removing Entries from DNS

   The most important consideration in removing DNS entries is be sure
   that an entity removing a DNS entry is only removing an entry that
   it added, or for which an administrator has explicitly assigned it
   responsibility.

   When a lease expires or a DHCP client issues a DHCPRELEASE request,
   the DHCP server SHOULD delete the PTR RR that matches the DHCP
   binding, if one was successfully added. The server's update query
   SHOULD assert that the name in the PTR record matches the name of
   the client whose lease has expired or been released.

   The entity chosen to handle the A record for this client (either the
   client or the server) SHOULD delete the A record that was added when
   the lease was made to the client.

   In order to perform this delete, the updater prepares an UPDATE
   query which contains two prerequisites.  The first prerequisite
   asserts that the DHCID RR exists whose data is the client identity
   described in Section 4.3. The second prerequisite asserts that the
   data in the A RR contains the IP address of the lease that has
   expired or been released.

   If the query fails, the updater MUST NOT delete the DNS name.  It
   may be that the host whose lease on the server has expired has moved
   to another network and obtained a lease from a different server,
   which has caused the client's A RR to be replaced. It may also be
   that some other client has been configured with a name that matches
   the name of the DHCP client, and the policy was that the last client


Stapp & Rekhter          Expires September 2000                [Page 15]

Internet-Draft      Interaction between DHCP and DNS          March 2000


   to specify the name would get the name.  In this case, the DHCID RR
   will no longer match the updater's notion of the client-identity of
   the host pointed to by the DNS name.

8.4 Updating other RRs

   The procedures described in this document only cover updates to the
   A and PTR RRs. Updating other types of RRs is outside the scope of
   this document.

9. Security Considerations

   Unauthenticated updates to the DNS can lead to tremendous confusion,
   through malicious attack or through inadvertent misconfiguration.
   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 request origin
   authentication procedure (e.g., Simple Secure DNS Update[11]) when
   performing DNS updates.

   Whether a DHCP client may be responsible for updating an FQDN to IP
   address mapping, or whether this is the responsibility of the DHCP
   server is a site-local matter. The choice between the two
   alternatives may be based on the security model that is used with
   the Dynamic DNS Update protocol (e.g., only a client may have
   sufficient credentials to perform updates to the FQDN to IP address
   mapping for its FQDN).

   Whether a DHCP server is always responsible for updating the FQDN to
   IP address mapping (in addition to updating the IP to FQDN mapping),
   regardless of the wishes of an individual DHCP client, is also a
   site-local matter. The choice between the two alternatives may be
   based on the security model that is being used with dynamic DNS
   updates. In cases where a DHCP server is performing DNS updates on
   behalf of a client, the DHCP server should be sure of the DNS name
   to use for the client, and of the identity of the client.

   Currently, it is difficult for DHCP servers to develop much
   confidence in the identities of its clients, given the absence of
   entity authentication from the DHCP protocol itself. There are many
   ways for a DHCP server to develop a DNS name to use for a client,
   but only in certain relatively unusual circumstances will the DHCP
   server know for certain the identity of the client. If DHCP
   Authentication[10] becomes widely deployed this may become more
   customary.

   One example of a situation which offers some extra assurances is one
   where the DHCP client is connected to a network through an MCNS
   cable modem, and the CMTS (head-end) of the cable modem ensures that


Stapp & Rekhter          Expires September 2000                [Page 16]

Internet-Draft      Interaction between DHCP and DNS          March 2000


   MAC address spoofing simply does not occur. Another example of a
   configuration that might be trusted is one where clients obtain
   network access via a network access server using PPP. The NAS itself
   might be obtaining IP addresses via DHCP, encoding a client
   identification into the DHCP client-id option.  In this case, the
   network access server as well as the DHCP server might be operating
   within a trusted environment, in which case the DHCP server could be
   configured to trust that the user authentication and authorization
   procedure of the remote access server was sufficient, and would
   therefore trust the client identification encoded within the DHCP
   client-id.

10. Acknowledgements

   Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter
   Ford, Edie Gunter, Andreas Gustafsson, R. Barr Hibbs, Kim Kinnear,
   Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Josh Littlefield,
   Michael Patton, and Glenn Stump for their review and comments.

References

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

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

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

   [4]  Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and
        Answers to Commonly asked ``New Internet User'' Questions", RFC
        1594, March 1994.

   [5]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
        Updates in the Domain Name System", RFC 2136, April 1997.

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

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

   [8]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
        August 1999.

   [9]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
        "Secret Key Transaction Authentication for DNS (TSIG)
        (draft-ietf-dnsext-tsig-*)", July 1999.


Stapp & Rekhter          Expires September 2000                [Page 17]

Internet-Draft      Interaction between DHCP and DNS          March 2000


   [10]  Droms, R. and W. Arbaugh, "Authentication for DHCP Messages
         (draft-ietf-dhc-authentication-*)", June 1999.

   [11]  Wellington, B., "Simple Secure DNS Dynamic Updates
         (draft-ietf-dnsext-simple-secure-update-*)", June 1999.

   [12]  Gustafsson, A., "A DNS RR for encoding DHCP client identity
         (draft-ietf-dnsext-dhcid-rr-*)", October 1999.

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

Authors' Addresses

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

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

   Yakov Rekhter
   Cisco Systems, Inc.
   170 Tasman Dr.
   San Jose, CA  95134
   US

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




















Stapp & Rekhter          Expires September 2000                [Page 18]

Internet-Draft      Interaction between DHCP and DNS          March 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 implmentation 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 & Rekhter          Expires September 2000                [Page 19]