DHC Working Group Carl Smith
Internet Draft Sun Microsystems, Inc.
Ted Lemon
Nominum, Inc.
Updates: RFC 2132 February 2002
Expires August 2002
Considerations for the use of the Host Name option
<draft-ietf-dhc-host-option-considerations-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document clarifies the use of the DHCP Host Name option. The
primary point of this clarification addresses the use of the option
by clients to request proxy DNS updates by DHCP servers.
1. Introduction
The initial concept of the Host Name option, as documented in RFC
1533[1] and duplicated in RFC 2132 [2], was simply to allow a DHCP
server to supply a client with its name (``This option specifies the
name of the client''). The DHCP client was merely a consumer of the
option information. Even in this case, confusion has been reported
in interactions with various domain name options.
Behavior of client and server when the client supplies the option
was, and still is, unspecified. In the intervening years, the
Smith & Lemon [Page 1]
RFC DRAFT February 2002
ability to easily update Domain Name Service information [3] has
encouraged the use of this option by DHCP clients as a way to request
that DHCP servers issue proxy DNS updates on their behalf. Lack of a
document describing its exact usage has led, as one would surely
expect, to interoperability problems. It is the purpose of this
document to outline the expectations that clients and servers should
have when using the Host Name option.
2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4]. This
document also uses the following terms:
"DHCP client"
DHCP client or "client" is an Internet host using DHCP to
obtain configuration parameters such as a network address.
"DHCP server"
A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients.
"FQDN"
A fully-qualified name, including the host part and Domain Name
system domain.
3. Interactions with Name Services
A DHCP client's use of the Host Name option should be fairly
straightforward, but users report problems, particularly with the
interactions between it and Domain Name option and between the DNS
(RFC 1034 [5] and RFC 1035 [6]) and other naming services so we
reiterate and expand the description of the expected behavior:
if a DHCP server supplies both Host Name and Domain Name options
to a client, the host name SHOULD NOT be fully-qualified
if a DHCP server supplies only a Host Name option, the host name
SHOULD be fully qualified; the server MUST append only DNS domain
names in forming a fully-qualified name
a client MUST check to see whether a Host Name option contains a
fully-qualified name and if so, MUST NOT append the value of the
Domain Name option (if present) in forming its fully-qualified
Smith & Lemon [Page 2]
RFC DRAFT February 2002
domain name
since a Host Name option's value may be fully-qualified only by
supplying the DNS domain name, a client that receives a fully-
qualified name in the Host Name option MAY infer the DNS domain
name from the suffix of the supplied host name. This inference
remains valid even in the presence of client configuration infor-
mation or policies that prefer other name services in favor of, or
in place of, DNS.
4. DNS Updates for DHCP Clients
DNS maintains Resource Records (RRs) for mapping between IP addresses
FQDNs. Specifically, A records map FQDNs to IP addresses and PTR
records map IP addresses to FQDNs. Several options are available to
DHCP clients interested in updating A and PTR records:
issuing direct updates to DNS
using the DHCP client FQDN option [7]
using the DHCP Host Name option
Either of the first two methods has the advantage of offering the
client a number of approaches for fine-tuning DNS update requests as
well as direct feedback on the success or failure of the intended
operations. Both are to be preferred over the latter: use of the
Host Name option does not even guarantee that the DHCP server will
attempt any DNS updates on a client's behalf. Nevertheless, support
for this method of requesting proxy DNS updates is widespread and it
may be viewed as appropriate for situations in which there are no
requirements for other finely-tunable methods.
4.1 DHCP Client Considerations and Behavior
A DHCP client that uses the Host Name option to request a DNS update
MUST be prepared to independently verify the success or failure of
the request before using the name in a manner that would imply its
validity. If a DHCP server returns the requested name in the
DHCPACK's Host Name option, the client MAY infer that the server has
honored its request.
There are a number of reasons that a DHCP server may fail to return a
Host Name option, so nothing should be inferred from the option's
absence in the DHCPACK. The client MAY supply the option on subse-
quent RENEW operations as a method of retrying the request. However,
if the Host Name option is absent in the DHCPACK, the client MUST NOT
use the requested name until it has verified the validity of the
Smith & Lemon [Page 3]
RFC DRAFT February 2002
association between it and the IP address supplied in the yiaddr
field. Moreover, if the name returned in the DHCPACK is different
from the one requested, the client MUST use the new name.
A DHCP client MAY send either an unqualified or fully-qualified name
in the Host Name option. Clients sending unqualified names are
implicitly relying on DHCP servers to associate the clients with the
appropriate zone before issuing any updates to DNS. A DHCP client in
INIT state SHOULD fill in the requested host name in the DHCPDISCOVER
packet. It MUST do so in its subsequent DHCPREQUEST packet.
Clients in states other than INIT SHOULD avoid ambiguity in their
requests by supplying the same Host Name option value on subsequent
DHCPREQUESTs as was supplied on their original (INIT state) DHCPRE-
QUEST.
A client that wishes to change its host name MAY request it by sup-
plying a Host Name option with the new name in a subsequent RENEW
request. As with the initial request, a client MUST NOT use the
newly-requested name until it has verified that it is now valid.
4.2 DHCP Server Considerations and Behavior
Use of the FQDN option makes it possible to easily separate update
operations into pieces corresponding to what are thought of as the
traditional ownership boundaries: DHCP servers own the addresses
they lease, while the clients own their names. This boundary is not
present when the Host Name option is used: the implied proxy update
request assumes that the DHCP server has sufficient privilege to
change both the A and PTR records. That is, it ``owns'' both.
For this and other reasons, use of the FQDN option is preferred: a
DHCP server that receives both a Host Name option and a client FQDN
option MUST prefer the FQDN option. In such a case, the server
SHOULD behave as if the Host Name option is not present.
A DHCP server MAY use the value of the Host Name option in a DHCPDIS-
COVER packet in some limited ways: it may check to see whether the
requested name belongs to an address that ls leaseable to the client,
saving the need for a DNS update, or it may begin preparation of an
update request. The server MUST wait for the DHCPREQUEST before ini-
tiating any update operations.
DNS updates may not complete in a timely manner, forcing the DHCP
server to reply to a client before the update has finished. Alterna-
tively, an error may be reported in response to the update request.
It is not possible to distinguish these cases for the client's bene-
fit, and the the DHCP server simply omits the Host Name option from
Smith & Lemon [Page 4]
RFC DRAFT February 2002
its DHCPACK. For simplicity of implementation, servers may choose to
``orphan'' any outstanding requests, taking no note of subsequent
reports of success or failure. Servers that choose to keep track of
the results of update requests SHOULD use successful completion
reports to avoid subsequent unnecessary work; those servers SHOULD
ignore reports of soft, transitory errors. Hard errors SHOULD be
logged by the server so that corrective action, if any, may be taken
by an administrator. Servers MAY choose to not cache hard failures,
retrying on subsequent DHCPREQUESTs in the hope that the errors
logged have led to a remedy.
Issuing DNS updates on behalf of DHCP clients is an inherently state-
ful operation. A DHCP server MUST commit to stable storage the
necessary information regarding any updates it successfully makes on
behalf of its clients. This state may be needed
when a lease expires
when communicating with a failover partner
on subsequent lease renewals
and may need to be recovered when the server is restarted.
When a lease expires, a DHCP server MAY use this stored information
to expunge the name-to-address association it created on the client's
behalf. Because the use of the Host Name option cedes the ownership
of the name to the server, a server MAY instead choose to allow the
association to continue, saving itself work now and possibly sparing
the need for a future update.
A server MAY choose to reevaluate the Host Name option each time a
client sends a RENEW request via a DHCPREQUEST, or the server MAY
choose to view the update request as an action to be taken once, upon
initial lease of an address. Servers that take the former view offer
their clients the possibility of changing the name associated with a
currently valid lease, but may incur additional processing costs
because of it. Servers taking the latter view do not afford clients
the opportunity to change names, but more importantly do not allow
them to retry failed requests, possibly even with different host
names. For this reason, the former behavior is preferred: servers
SHOULD reevaluate the Host Name option on each RENEW.
Some servers interpret a Host Name option on the initial DHCPREQUEST,
followed by the absence of the option on subsequent RENEW DHCPRE-
QUESTs as a request by the client to delete a name-to-address associ-
ation. Here we invoke the principle of least surprise: it is more
reasonable for a client to expect that DNS updates apply for the
Smith & Lemon [Page 5]
RFC DRAFT February 2002
duration of a lease than it is to expect that a client will wish to
delete an update but retain the lease. Because clients that expect
DNS updates to apply for the duration of a lease may not send a Host
Name option when RENEWing, servers SHOULD NOT interpret the absence
of the option as a request for deletion of the association.
5. References
[1] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, October 1993.
[2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[3] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates
in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[4] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[5] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
1034, November 1987.
[6] Mockapetris, P., "Domain names - Implementation and Specifica-
tion", RFC 1035, November 1987.
[7] Stapp, M. and Rekhter, Y., "The DHCP Client FQDN Option", draft-
ietf-dhc-fqdn-option-03.txt, November 2001.
6. Author Information
Carl Smith
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94043
USA
email: cs@Eng.Sun.COM
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
USA
email: Ted.Lemon@nominum.com
7. Expiration
This document will expire on August 22, 2002.
8. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
Smith & Lemon [Page 6]
RFC DRAFT February 2002
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 develop-
ing 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 MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Smith & Lemon [Page 7]
