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

DHCP服务器源码

   4.  Server updates the A RR, uses a name supplied by the client.
       Name collisions in this scenario are highly likely, even with
       administrative procedures designed to prevent them.  (This
       scenario is a popular one in real-world deployments in many
       types of organizations.)  See Section 9 for security issues with
       this type of deployment.


   Scenarios 2, 3, and 4 rely on administrative procedures to ensure
   name uniqueness for DNS updates, and these procedures may break
   down. Experience has shown that, in fact, these procedures will
   break down at least occasionally.  The question is what to do when


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


   these procedures break down or, for example in scenario #4, may not
   even exist.

   In all cases of name collisions, the desire is to offer two modes of
   operation to the administrator of the combined DHCP-DNS capability:
   first-update-wins (i.e., the first updating entity gets the name) or
   most-recent-update-wins (i.e., the last updating entity for a name
   gets the name).

4.2 Multiple DHCP servers

   If multiple DHCP servers are able to update the same DNS zones, or
   if DHCP servers are performing A RR updates on behalf of DHCP
   clients, and more than one DHCP server may be able to serve
   addresses to the same DHCP clients, the DHCP servers should be able
   to provide reasonable and consistent DNS name update behavior for
   DHCP clients.

4.3 Use of the DHCID RR

   A solution to both of these problems is for the updating entities
   (both DHCP clients and DHCP servers) to be able to detect that
   another entity has been associated with a DNS name, and to offer
   administrators the opportunity to configure update behavior.

   Specifically, a DHCID RR, described in DHCID RR[12] is used to
   associate client identification information with a DNS name and the
   A RR associated with that name.  When either a client or server adds
   an A RR for a client, it also adds a DHCID RR which specifies a
   unique client identity (based on a "client specifier" created from
   the client's client-id or MAC address).  In this model, only one A
   RR is associated with a given DNS name at a time.

   By associating this ownership information with each A RR,
   cooperating DNS updating entities may determine whether their client
   is the first or last updater of the name (and implement the
   appropriately configured administrative policy), and DHCP clients
   which currently have a host name may move from one DHCP server to
   another without losing their DNS name.

   The specific algorithms utilizing the DHCID RR to signal client
   ownership are explained below.  The algorithms only work in the case
   where the updating entities all cooperate -- this approach is
   advisory only and is not substitute for DNS security, nor is it
   replaced by DNS security.

4.3.1 Format of the DHCID RRDATA

   The DHCID RR used to hold the DHCP client's identity is formatted as


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


   follows:

   The name of the DHCID RR is the name of the A or PTR RR which refers
   to the DHCP client.

   The RDATA section of a DHCID RR in transmission contains RDLENGTH
   bytes of binary data. From the perspective of DHCP clients and
   servers, the DHC 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 client's link-layer address is being used to
   identify it, and one that is used when some DHCP option that the
   DHCP client has sent is being used to identify it.
      

      DISCUSSION:
      Implementors should note that the actual identifying data is
      never placed into the DNS directly. Instead, the client-identity
      data is used as the input into a one-way hash algorithm, and the
      output of that hash is then used as DNS RRDATA. This has been
      specified in order to avoid placing data about DHCP clients that
      some sites might consider sensitive into the DNS.

   When the updater is using the client's link-layer address, the first
   two bytes of the DHCID RRDATA MUST be zero. To generate the rest of
   the resource record, the updater MUST compute a one-way hash using
   the MD5[13] algorithm across a buffer containing the client's
   network hardware type and link-layer address. Specifically, the
   first byte of the buffer contains the network hardware type as it
   appears 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.

   When the updater is using a DHCP option sent by the client in its
   DHCPREQUEST message, the first two bytes of the DHCID RR MUST be the
   option code of that option, in network byte order. For example, if
   the DHCP client identifier option is being used, the first byte of
   the DHCID RR should be zero, and the second byte should be 61
   decimal. The rest of the DHCID RR MUST contain the results of
   computing a one-way hash across the payload of the option being
   used, using the MD5 algorithm. The payload of a DHCP option consists
   of the bytes of the option following the option code and length.

   In order for independent DHCP implementations to be able to use the
   DHCID RR as a prerequisite in dynamic DNS updates, each updater must
   be able to reliably choose the same identifier that any other would
   choose.  To make this possible, we specify a prioritization which


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


   will ensure that for any given DHCP client request, any updater will
   select the same client-identity data.  All updaters MUST use this
   order of prioritization by default, but all implementations SHOULD
   be configurable to use a different prioritization if so desired by
   the site administrators.  Because of the possibility of future
   changes in the DHCP protocol, implementors SHOULD check for updated
   versions of this draft when implementing new DHCP clients and
   servers which can perform DDNS updates, and also when releasing new
   versions of existing clients and servers.

   DHCP clients and servers should use the following forms of client
   identification, starting with the most preferable, and finishing
   with the least preferable.  If the client does not send any of these
   forms of identification, the DHCP/DDNS interaction is not defined by
   this specification.  The most preferable form of identification is
   the Globally Unique Identifier Option [TBD].  Next is the DHCP
   Client Identifier option.  Last is the client's link-layer address,
   as conveyed in its DHCPREQUEST message.  Implementors should note
   that the link-layer address cannot be used if there are no
   significant bytes in the chaddr field of the DHCP client's request,
   because this does not constitute a unique identifier.

4.4 DNS RR TTLs

   RRs associated with DHCP clients may be more volatile than
   statically configured RRs. DHCP clients and servers which perform
   dynamic updates should attempt to specify resource record TTLs which
   reflect this volatility, in order to minimize the possibility that
   there will be stale records in resolvers' caches. A reasonable basis
   for RR TTLs is the lease duration itself: TTLs of 1/2 or 1/3 the
   expected lease duration might be reasonable defaults. Because
   configured DHCP lease times vary widely from site to site, it may
   also be desirable to establish a fixed TTL ceiling. DHCP clients and
   servers MAY allow administrators to configure the TTLs they will
   supply, possibly as a fraction of the actual lease time, or as a
   fixed value.

5. Client FQDN Option

   To update the IP address to FQDN mapping a DHCP server needs to know
   the FQDN of the client to which the server leases the address. To
   allow the client to convey its FQDN to the server this document
   defines a new DHCP option, called "Client FQDN". The FQDN Option
   also contains Flags and RCode fields which DHCP servers can use to
   convey information about DNS updates to clients. 

   Clients MAY send the FQDN option, setting appropriate Flags values,
   in both their DISCOVER and REQUEST messages. If a client sends the
   FQDN option in its DISCOVER message, it MUST send the option in


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


   subsequent REQUEST messages. 

   The code for this option is 81. Its minimum length is 4.


        Code   Len    Flags  RCODE1 RCODE2   Domain Name
       +------+------+------+------+------+------+--
       |  81  |   n  |      |      |      |       ...
       +------+------+------+------+------+------+--


5.1 The Flags Field


        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |   MBZ   |E|O|S|
       +-+-+-+-+-+-+-+-+


   When a DHCP client sends the FQDN option in its DHCPDISCOVER and/or
   DHCPREQUEST messages, it sets the right-most bit (labelled "S") to
   indicate that it will not perform any Dynamic DNS updates, and that
   it expects the DHCP server to perform any FQDN-to-IP (the A RR) DNS
   update on its behalf. If this bit is clear, the client indicates
   that it intends to maintain its own FQDN-to-IP mapping update. 

   If a DHCP server intends to take responsibility for the A RR update
   whether or not the client sending the FQDN option has set the "S"
   bit, it sets both the "O" bit and the "S" bit, and sends the FQDN
   option in its DHCPOFFER and/or DHCPACK messages. 

   The data in the Domain Name field may appear in one of two formats:
   ASCII, or DNS-style binary encoding (without compression, of
   course), as described in RFC1035[2]. A client which sends the FQDN
   option MUST set the "E" bit to indicate that the data in the Domain
   Name field is DNS binary encoded. If a server receives an FQDN
   option from a client, and intends to include an FQDN option in its
   reply, it MUST use the same encoding that the client used. The DNS
   encoding is recommended. The use of ASCII-encoded domain-names is
   fragile, and the use of ASCII encoding in this option should be
   considered deprecated. 

   The remaining bits in the Flags field are reserved for future
   assignment. DHCP clients and servers which send the FQDN option MUST
   set the MBZ bits to 0, and they MUST ignore values in the part of
   the field labelled "MBZ". 




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


5.2 The RCODE Fields

   The RCODE1 and RCODE2 fields are used by a DHCP server to indicate
   to a DHCP client the Response Code from any A or PTR RR Dynamic DNS
   Updates it has performed. The server may also use these fields to
   indicate whether it has attempted such an update before sending the
   DHCPACK message. Each of these fields is one byte long.

   Implementors should note that EDNS0 describes a mechanism for
   extending the length of a DNS RCODE to 12 bits. EDNS0 is specified
   in RFC2671[8]. Only the least-significant 8 bits of the RCODE from a
   Dynamic DNS Update will be carried in the Client FQDN DHCP Option.
   This provides enough number space to accomodate the RCODEs defined
   in the Dynamic DNS Update specification.

5.3 The Domain Name Field

   The Domain Name part of the option carries all or part of the FQDN
   of a DHCP client. A client may be configured with a fully-qualified
   domain name, or with a partial name that is not fully-qualified. If
   a client knows only part of its name, it MAY send a single label,
   indicating that it knows part of the name but does not necessarily
   know the zone in which the name is to be embedded. The data in the
   Domain Name field may appear in one of two formats: ASCII (with no