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

DHCP服务器源码

   terminating NULL), or DNS encoding as specified in RFC1035[2]. If
   the DHCP client wishes to use DNS encoding, it MUST set the
   third-from-rightmost bit in the Flags field (the "E" bit); if it
   uses ASCII encoding, it MUST clear the "E" bit.

   A DHCP client that can only send a single label using ASCII encoding
   includes a series of ASCII characters in the Domain Name field,
   excluding the "." (dot) character. The client SHOULD follow the
   character-set recommendations of RFC1034[1] and RFC1035[2]. A client
   using DNS binary encoding which wants to suggest part of its FQDN
   MAY send a non-terminal sequence of labels in the Domain Name part
   of the option.

6. DHCP Client behavior

   The following describes the behavior of a DHCP client that
   implements the Client FQDN option.

   If a client that owns/maintains its own FQDN wants to be responsible
   for updating the FQDN to IP address mapping for the FQDN and
   address(es) used by the client, then the client MUST include the
   Client FQDN option in the DHCPREQUEST message originated by the
   client. A DHCP client MAY choose to include the Client FQDN option
   in its DISCOVER messages as well as its REQUEST messages. The
   rightmost ("S") bit in the Flags field in the option MUST be set to


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


   0. Once the client's DHCP configuration is completed (the client
   receives a DHCPACK message, and successfully completes a final check
   on the parameters passed in the message), the client MAY originate
   an update for the A RR (associated with the client's FQDN). The
   update MUST be originated following the procedures described in
   RFC2136[5] and Section 8. If the DHCP server from which the client
   is requesting a lease includes the FQDN option in its ACK message,
   and if the server sets both the "S" and the "O" bits (the two
   rightmost bits) in the option's flags field, the DHCP client MUST
   NOT initiate an update for the name in the Domain Name field.

   A client can choose to delegate the responsibility for updating the
   FQDN to IP address mapping for the FQDN and address(es) used by the
   client to the server.  In order to inform the server of this choice,
   the client SHOULD include the Client FQDN option in its DHCPREQUEST
   message. The rightmost (or "S") bit in the Flags field in the option
   MUST be set to 1. A client which delegates this responsibility MUST
   NOT attempt to perform a Dynamic DNS update for the name in the
   Domain Name field of the FQDN option. The client MAY supply an FQDN
   in the Client FQDN option, or it MAY supply a single label (the
   most-specific label), or it MAY leave that field empty as a signal
   to the server to generate an FQDN for the client in any manner the
   server chooses.

   Since there is a possibility that the DHCP server may be configured
   to complete or replace a domain name that the client was configured
   to send, the client might find it useful to send the FQDN option in
   its DISCOVER messages. If the DHCP server returns different Domain
   Name data in its OFFER message, the client could use that data in
   performing its own eventual A RR update, or in forming the FQDN
   option that it sends in its REQUEST message. There is no requirement
   that the client send identical FQDN option data in its DISCOVER and
   REQUEST messages. In particular, if a client has sent the FQDN
   option to its server, and the configuration of the client changes so
   that its notion of its domain name changes, it MAY send the new name
   data in an FQDN option when it communicates with the server again.
   This may allow the DHCP server to update the name associated with
   the PTR record, and, if the server updated the A record representing
   the client, to delete that record and attempt an update for the
   client's current domain name.

   A client that delegates the responsibility for updating the FQDN to
   IP address mapping to a server might not receive any indication
   (either positive or negative) from the server whether the server was
   able to perform the update. In this case the client MAY use a DNS
   query to check whether the mapping is updated.

   A client MUST set the RCODE1 and RCODE2 fields in the Client FQDN
   option to 0 when sending the option.


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


   If a client releases its lease prior to the lease expiration time
   and the client is responsible for updating its A RR, the client
   SHOULD delete the A RR (following the procedures described in
   Section 8) associated with the leased address before sending a DHCP
   RELEASE message. Similarly, if a client was responsible for updating
   its A RR, but is unable to renew its lease, the client SHOULD
   attempt to delete the A RR before its lease expires. A DHCP client
   which has not been able to delete an A RR which it added (because it
   has lost the use of its DHCP IP address) should attempt to notify
   its administrator.

7. DHCP Server behavior

   When a server receives a DHCPREQUEST message from a client, if the
   message contains the Client FQDN option, and the server replies to
   the message with a DHCPACK message, the server may be configured to
   originate an update for the PTR RR (associated with the address
   leased to the client). Any such update MUST be originated following
   the procedures described in Section 8. The server MAY complete the
   update before the server sends the DHCPACK message to the client. In
   this case the RCODE from the update MUST be carried to the client in
   the RCODE1 field of the Client FQDN option in the DHCPACK message.
   Alternatively, the server MAY send the DHCPACK message to the client
   without waiting for the update to be completed. In this case the
   RCODE1 field of the Client FQDN option in the DHCPACK message MUST
   be set to 255.  The choice between the two alternatives is entirely
   determined by the configuration of the DHCP server. Servers SHOULD
   support both configuration options.

   When a server receives a DHCPREQUEST message containing the Client
   FQDN option, the server MUST ignore the values carried in the RCODE1
   and RCODE2 fields of the option.

   In addition, if the Client FQDN option carried in the DHCPREQUEST
   message has the "S" bit in its Flags field set, then the server MAY
   originate an update for the A RR (associated with the FQDN carried
   in the option) if it is configured to do so by the site's
   administrator, and if it has the necessary credentials. The server
   MAY be configured to use the name supplied in the client's FQDN
   option, or it MAY be configured to modify the supplied name, or
   substitute a different name.

   Any such update MUST be originated following the procedures
   described in Section 8. The server MAY originate the update before
   the server sends the DHCPACK message to the client. In this case the
   RCODE from the update [RFC2136] MUST be carried to the client in the
   RCODE2 field of the Client FQDN option in the DHCPACK message. 
   Alternatively the server MAY send the DHCPACK message to the client
   without waiting for the update to be completed. In this case the


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


   RCODE2 field of the Client FQDN option in the DHCPACK message MUST
   be set to 255. The choice between the two alternatives is entirely
   up to the DHCP server. In either case, if the server intends to
   perform the DNS update and the client's REQUEST message included the
   FQDN option, the server SHOULD include the FQDN option in its ACK
   message, and MUST set the "S" bit in the option's Flags field.

   Even if the Client FQDN option carried in the DHCPREQUEST message
   has the "S" bit in its Flags field clear (indicating that the client
   wants to update the A RR), the server MAY be configured by the local
   administrator to update the A RR on the client's behalf. A server
   which is configured to override the client's preference SHOULD
   include an FQDN option in its ACK message, and MUST set both the "O"
   and "S" bits in the FQDN option's Flags field. The update MUST be
   originated following the procedures described in Section 8. The
   server MAY originate the update before the server sends the DHCPACK
   message to the client. In this case the RCODE from the update
   [RFC2136] MUST be carried to the client in the RCODE2 field of the
   Client FQDN option in the DHCPACK message. Alternatively, the server
   MAY send the DHCPACK message to the client without waiting for the
   update to be completed. In this case the RCODE2 field of the Client
   FQDN option in the DHCPACK message MUST be set to 255. Whether the
   DNS update occurs before or after the DHCPACK is sent is entirely up
   to the DHCP server's configuration.

   When a DHCP server sends the Client FQDN option to a client in the
   DHCPACK message, the DHCP server SHOULD send its notion of the
   complete FQDN for the client in the Domain Name field. The server
   MAY simply copy the Domain Name field from the Client FQDN option
   that the client sent to the server in the DHCPREQUEST message. The
   DHCP server MAY be configured to complete or modify the domain name
   which a client sent, or it MAY be configured to substitute a
   different name. If the server initiates a DDNS update which is not
   complete until after the server has replied to the DHCP client, the
   server's The server MUST use the same encoding format (ASCII or DNS
   binary encoding) that the client used in the FQDN option in its
   DHCPREQUEST, and MUST set the "E" bit in the option's Flags field
   accordingly.

   If a client's DHCPREQUEST message doesn't carry the Client FQDN
   option (e.g., the client doesn't implement the Client FQDN option),
   the server MAY be configured to update either or both of the A and
   PTR RRs. The updates MUST be originated following the procedures
   described in Section 8.

   If a server detects that a lease on an address that the server
   leases to a client has expired, the server SHOULD delete any PTR RR
   which it added via dynamic update. In addition, if the server added
   an A RR on the client's behalf, the server SHOULD also delete the A


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


   RR. The deletion MUST follow the procedures described in Section 8.

   If a server terminates a lease on an address prior to the lease's
   expiration time, for instance by sending a DHCPNAK to a client, the
   server SHOULD delete any PTR RR which it associated with the address
   via DNS Dynamic Update. In addition, if the server took
   responsibility for an A RR, the server SHOULD also delete that A RR.
   The deletion MUST follow the procedures described in Section 8.

8. Procedures for performing DNS updates

8.1 Adding A RRs to DNS

   When a DHCP client or server intends to update an A RR, it first
   prepares a DNS UPDATE query which includes as a prerequisite the
   assertion that the name does not exist.  The update section of the
   query attempts to add the new name and its IP address mapping (an A
   RR), and the DHCID RR with its unique client-identity.

   If this update operation succeeds, the updater can conclude that it
   has added a new name whose only RRs are the A and DHCID RR records.
   The A RR update is now complete (and a client updater is finished,
   while a server might proceed to perform a PTR RR update).

   If the first update operation fails with YXDOMAIN, the updater can
   conclude that the intended name is in use.  The updater then
   attempts to confirm that the DNS name is not being used by some
   other host. The updater prepares a second UPDATE query in which the
   prerequisite is that the desired name has attached to it a DHCID RR
   whose contents match the client identity.  The update section of
   this query deletes the existing A records on the name, and adds the
   A record that matches the DHCP binding and the DHCID RR with the
   client identity.

   If this query succeeds, the updater can conclude that the current
   client was the last client associated with the domain name, and that
   the name now contains the updated A RR. The A RR update is now
   complete (and a client updater is finished, while a server would
   then proceed to perform a PTR RR update).

   If the second query fails with NXRRSET, the updater must conclude
   that the client's desired name is in use by another host.  At this
   juncture, the updater can decide (based on some administrative
   configuration outside of the scope of this document) whether to let
   the existing owner of the name keep that name, and to (possibly)
   perform some name disambiguation operation on behalf of the current
   client, or to replace the RRs on the name with RRs that represent
   the current client. If the configured policy allows replacement of
   existing records, the updater submits a query that deletes the


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


   existing A RR and the existing DHCID RR, adding A and DHCID RRs that
   represent the IP address and client-identity of the new client.
      

      DISCUSSION:
      The updating entity may be configured to allow the existing DNS
      records on the domain name to remain unchanged, and to perform
      disambiguation on the name of the current client in order to
      attempt to generate a similar but unique name for the current
      client. In this case, once another candidate name has been
      generated, the updater should restart the process of adding an A
      RR as specified in this section.