tools/adflib: build only host variant which is used by Sam440 target
[AROS.git] / workbench / network / stacks / AROSTCP / dhcp / doc / draft-ietf-dhc-dhcp-dns-12.txt
blobc97ba6253029385752fdbc9a8959d9e8bcc4d9da
3 DHC Working Group                                               M. Stapp
4 Internet-Draft                                                Y. Rekhter
5 Expires: September 2000                              Cisco Systems, Inc.
6                                                           March 10, 2000
9                     Interaction between DHCP and DNS
10                     <draft-ietf-dhc-dhcp-dns-12.txt>
12 Status of this Memo
14    This document is an Internet-Draft and is in full conformance with
15    all provisions of Section 10 of RFC2026.
17    Internet-Drafts are working documents of the Internet Engineering
18    Task Force (IETF), its areas, and its working groups. Note that
19    other groups may also distribute working documents as
20    Internet-Drafts.
22    Internet-Drafts are draft documents valid for a maximum of six
23    months and may be updated, replaced, or obsoleted by other documents
24    at any time. It is inappropriate to use Internet-Drafts as reference
25    material or to cite them other than as "work in progress."
27    To view the entire list of Internet-Draft Shadow Directories, see
28    http://www.ietf.org/shadow.html.
30    This Internet-Draft will expire on September 2000.
32 Copyright Notice
34    Copyright (C) The Internet Society (2000). All Rights Reserved.
36 Abstract
38    DHCP provides a powerful mechanism for IP host configuration.
39    However, the configuration capability provided by DHCP does not
40    include updating DNS, and specifically updating the name to address
41    and address to name mappings maintained in the DNS.
43    This document specifies how DHCP clients and servers should use the
44    Dynamic DNS Updates mechanism in RFC2136[5] to update the DNS name
45    to address and address to name mappings so that the mappings for
46    DHCP clients will be consistent with the IP addresses that the
47    clients acquire via DHCP.
55 Stapp & Rekhter          Expires September 2000                 [Page 1]
57 Internet-Draft      Interaction between DHCP and DNS          March 2000
60 Table of Contents
62    1.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
63    2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
64    3.    Models of Operation  . . . . . . . . . . . . . . . . . . . .  3
65    4.    Issues with DDNS in DHCP Environments  . . . . . . . . . . .  4
66    4.1   Name Collisions  . . . . . . . . . . . . . . . . . . . . . .  5
67    4.2   Multiple DHCP servers  . . . . . . . . . . . . . . . . . . .  6
68    4.3   Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . .  6
69    4.3.1 Format of the DHCID RRDATA . . . . . . . . . . . . . . . . .  6
70    4.4   DNS RR TTLs  . . . . . . . . . . . . . . . . . . . . . . . .  8
71    5.    Client FQDN Option . . . . . . . . . . . . . . . . . . . . .  8
72    5.1   The Flags Field  . . . . . . . . . . . . . . . . . . . . . .  9
73    5.2   The RCODE Fields . . . . . . . . . . . . . . . . . . . . . . 10
74    5.3   The Domain Name Field  . . . . . . . . . . . . . . . . . . . 10
75    6.    DHCP Client behavior . . . . . . . . . . . . . . . . . . . . 10
76    7.    DHCP Server behavior . . . . . . . . . . . . . . . . . . . . 12
77    8.    Procedures for performing DNS updates  . . . . . . . . . . . 14
78    8.1   Adding A RRs to DNS  . . . . . . . . . . . . . . . . . . . . 14
79    8.2   Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . 15
80    8.3   Removing Entries from DNS  . . . . . . . . . . . . . . . . . 15
81    8.4   Updating other RRs . . . . . . . . . . . . . . . . . . . . . 16
82    9.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
83    10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
84          References . . . . . . . . . . . . . . . . . . . . . . . . . 17
85          Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
86          Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
111 Stapp & Rekhter          Expires September 2000                 [Page 2]
113 Internet-Draft      Interaction between DHCP and DNS          March 2000
116 1. Terminology
118    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
120    document are to be interpreted as described in RFC 2119[6].
122 2. Introduction
124    DNS (RFC1034[1], RFC1035[2]) maintains (among other things) the
125    information about mapping between hosts' Fully Qualified Domain
126    Names (FQDNs) RFC1594[4] and IP addresses assigned to the hosts. The
127    information is maintained in two types of Resource Records (RRs): A
128    and PTR. The A RR contains mapping from a FQDN to an IP address; the
129    PTR RR contains mapping from an IP address to a FQDN.  The Dynamic
130    DNS Updates specification (RFC2136[5]) describes a mechanism that
131    enables DNS information to be updated over a network. 
133    DHCP RFC2131[3] provides a mechanism by which a host (a DHCP client)
134    can acquire certain configuration information, along with its IP
135    address(es). However, DHCP does not provide any mechanisms to update
136    the DNS RRs that contain the information about mapping between the
137    host's FQDN and its IP address(es) (A and PTR RRs). Thus the
138    information maintained by DNS for a DHCP client may be incorrect - a
139    host (the client) could acquire its address by using DHCP, but the A
140    RR for the host's FQDN wouldn't reflect the address that the host
141    acquired, and the PTR RR for the acquired address wouldn't reflect
142    the host's FQDN.
144    The Dynamic DNS Update protocol can be used to maintain consistency
145    between the information stored in the A and PTR RRs and the actual
146    address assignment done via DHCP. When a host with a particular FQDN
147    acquires its IP address via DHCP, the A RR associated with the
148    host's FQDN would be updated (by using the Dynamic DNS Updates
149    protocol) to reflect the new address. Likewise, when an IP address
150    is assigned to a host with a particular FQDN, the PTR RR associated
151    with this address would be updated (using the Dynamic DNS Updates
152    protocol) to reflect the new FQDN.
154    Although this document refers to the A and PTR DNS record types and
155    to DHCP assignment of IPv4 addresses, the same procedures and
156    requirements apply for updates to the analogous RR types that are
157    used when clients are assigned IPv6 addresses via DHCPv6.
159 3. Models of Operation
161    When a DHCP client acquires a new address, a site's administrator
162    may desire that one or both of the A RR for the client's FQDN and
163    the PTR RR for the acquired address be updated. Therefore, two
164    separate Dynamic DNS Update transactions occur. Acquiring an address
167 Stapp & Rekhter          Expires September 2000                 [Page 3]
169 Internet-Draft      Interaction between DHCP and DNS          March 2000
172    via DHCP involves two entities: a DHCP client and a DHCP server. In
173    principle each of these entities could perform none, one, or both of
174    the transactions. However, in practice not all permutations make
175    sense. This document covers these possible design permutations:
177    1.  DHCP client updates the A RR, DHCP server updates the PTR RR
178    2.  DHCP server updates both the A and the PTR RRs
180    The only difference between these two cases is whether the FQDN to
181    IP address mapping is updated by a DHCP client or by a DHCP server.
182    The IP address to FQDN mapping is updated by a DHCP server in both
183    cases. 
185    The reason these two are important, while others are unlikely, has
186    to do with authority over the respective DNS domain names. A DHCP
187    client may be given authority over mapping its own A RRs, or that
188    authority may be restricted to a server to prevent the client from
189    listing arbitrary addresses or associating its address with
190    arbitrary domain names. In all cases, the only reasonable place for
191    the authority over the PTR RRs associated with the address is in the
192    DHCP server that allocates the address.
194    In any case, whether a site permits all, some, or no DHCP servers
195    and clients to perform DNS updates into the zones which it controls
196    is entirely a matter of local administrative policy. This document
197    does not require any specific administrative policy, and does not
198    propose one. The range of possible policies is very broad, from
199    sites where only the DHCP servers have been given credentials that
200    the DNS servers will accept, to sites where each individual DHCP
201    client has been configured with credentials which allow the client
202    to modify its own domain name. Compliant implementations MAY support
203    some or all of these possibilities. Furthermore, this specification
204    applies only to DHCP client and server processes: it does not apply
205    to other processes which initiate dynamic DNS updates. 
207    This document describes a new DHCP option which a client can use to
208    convey all or part of its domain name to a DHCP server.
209    Site-specific policy determines whether DHCP servers use the names
210    that clients offer or not, and what DHCP servers may do in cases
211    where clients do not supply domain names. 
213 4. Issues with DDNS in DHCP Environments
215    There are two DNS update situations that require special
216    consideration in DHCP environments: cases where more than one DHCP
217    client has been configured with the same FQDN, and cases where more
218    than one DHCP server has been given authority to perform DNS updates
219    in a zone. In these cases, it is possible for DNS records to be
220    modified in inconsistent ways unless the updaters have a mechanism
221    that allows them to detect anomolous situations. If DNS updaters can
224 Stapp & Rekhter          Expires September 2000                 [Page 4]
226 Internet-Draft      Interaction between DHCP and DNS          March 2000
229    detect these situations, site administrators can configure the
230    updaters' behavior so that the site's policies can be enforced. We
231    use the term "Name Collisions" to refer to cases where more than one
232    DHCP client has been associated with a single FQDN. This
233    specification describes a mechanism designed to allow updaters to
234    detect these situations, and requires that DHCP implementations use
235    this mechanism by default.
237 4.1 Name Collisions
239    How can the entity updating an A RR (either the DHCP client or DHCP
240    server) detect that a domain name has an A RR which is already in
241    use by a different DHCP client? Similarly, should a DHCP client or
242    server update a domain name which has an A RR that has been
243    configured by an administrator?  In either of these cases, the
244    domain name in question would either have an additional A RR, or
245    would have its original A RR replaced by the new record. Either of
246    these effects may be considered undesirable by some sites. Different
247    authority and credential models have different levels of exposure to
248    name collisions. 
250    1.  Client updates A RR, uses Secure DNS Update with credentials
251        that are associated with the client's FQDN, and exclusive to the
252        client. Name collisions in this scenario are unlikely (though
253        not impossible), since the client has received credentials
254        specific to the name it desires to use.  This implies that the
255        name has already been allocated (through some implementation- or
256        organization-specific procedure) to that client.
258    2.  Client updates A RR, uses Secure DNS Update with credentials
259        that are valid for any name in the zone. Name collisions in this
260        scenario are possible, since the credentials necessary for the
261        client to update DNS are not necessarily name-specific.  Thus,
262        for the client to be attempting to update a unique name requires
263        the existence of some administrative procedure to ensure client
264        configuration with unique names.
266    3.  Server updates the A RR, uses a name for the client which is
267        known to the server. Name collisions in this scenario are likely
268        unless prevented by the server's name configuration procedures.
269        See Section 9 for security issues with this form of deployment.
271    4.  Server updates the A RR, uses a name supplied by the client.
272        Name collisions in this scenario are highly likely, even with
273        administrative procedures designed to prevent them.  (This
274        scenario is a popular one in real-world deployments in many
275        types of organizations.)  See Section 9 for security issues with
276        this type of deployment.
279    Scenarios 2, 3, and 4 rely on administrative procedures to ensure
280    name uniqueness for DNS updates, and these procedures may break
281    down. Experience has shown that, in fact, these procedures will
282    break down at least occasionally.  The question is what to do when
285 Stapp & Rekhter          Expires September 2000                 [Page 5]
287 Internet-Draft      Interaction between DHCP and DNS          March 2000
290    these procedures break down or, for example in scenario #4, may not
291    even exist.
293    In all cases of name collisions, the desire is to offer two modes of
294    operation to the administrator of the combined DHCP-DNS capability:
295    first-update-wins (i.e., the first updating entity gets the name) or
296    most-recent-update-wins (i.e., the last updating entity for a name
297    gets the name).
299 4.2 Multiple DHCP servers
301    If multiple DHCP servers are able to update the same DNS zones, or
302    if DHCP servers are performing A RR updates on behalf of DHCP
303    clients, and more than one DHCP server may be able to serve
304    addresses to the same DHCP clients, the DHCP servers should be able
305    to provide reasonable and consistent DNS name update behavior for
306    DHCP clients.
308 4.3 Use of the DHCID RR
310    A solution to both of these problems is for the updating entities
311    (both DHCP clients and DHCP servers) to be able to detect that
312    another entity has been associated with a DNS name, and to offer
313    administrators the opportunity to configure update behavior.
315    Specifically, a DHCID RR, described in DHCID RR[12] is used to
316    associate client identification information with a DNS name and the
317    A RR associated with that name.  When either a client or server adds
318    an A RR for a client, it also adds a DHCID RR which specifies a
319    unique client identity (based on a "client specifier" created from
320    the client's client-id or MAC address).  In this model, only one A
321    RR is associated with a given DNS name at a time.
323    By associating this ownership information with each A RR,
324    cooperating DNS updating entities may determine whether their client
325    is the first or last updater of the name (and implement the
326    appropriately configured administrative policy), and DHCP clients
327    which currently have a host name may move from one DHCP server to
328    another without losing their DNS name.
330    The specific algorithms utilizing the DHCID RR to signal client
331    ownership are explained below.  The algorithms only work in the case
332    where the updating entities all cooperate -- this approach is
333    advisory only and is not substitute for DNS security, nor is it
334    replaced by DNS security.
336 4.3.1 Format of the DHCID RRDATA
338    The DHCID RR used to hold the DHCP client's identity is formatted as
341 Stapp & Rekhter          Expires September 2000                 [Page 6]
343 Internet-Draft      Interaction between DHCP and DNS          March 2000
346    follows:
348    The name of the DHCID RR is the name of the A or PTR RR which refers
349    to the DHCP client.
351    The RDATA section of a DHCID RR in transmission contains RDLENGTH
352    bytes of binary data. From the perspective of DHCP clients and
353    servers, the DHC resource record consists of a 16-bit identifier
354    type, followed by one or more bytes representing the actual
355    identifier. There are two possible forms for a DHCID RR - one that
356    is used when the client's link-layer address is being used to
357    identify it, and one that is used when some DHCP option that the
358    DHCP client has sent is being used to identify it.
359       
361       DISCUSSION:
362       Implementors should note that the actual identifying data is
363       never placed into the DNS directly. Instead, the client-identity
364       data is used as the input into a one-way hash algorithm, and the
365       output of that hash is then used as DNS RRDATA. This has been
366       specified in order to avoid placing data about DHCP clients that
367       some sites might consider sensitive into the DNS.
369    When the updater is using the client's link-layer address, the first
370    two bytes of the DHCID RRDATA MUST be zero. To generate the rest of
371    the resource record, the updater MUST compute a one-way hash using
372    the MD5[13] algorithm across a buffer containing the client's
373    network hardware type and link-layer address. Specifically, the
374    first byte of the buffer contains the network hardware type as it
375    appears in the DHCP htype field of the client's DHCPREQUEST message.
376    All of the significant bytes of the chaddr field in the client's
377    DHCPREQUEST message follow, in the same order in which the bytes
378    appear in the DHCPREQUEST message. The number of significant bytes
379    in the chaddr field is specified in the hlen field of the
380    DHCPREQUEST message.
382    When the updater is using a DHCP option sent by the client in its
383    DHCPREQUEST message, the first two bytes of the DHCID RR MUST be the
384    option code of that option, in network byte order. For example, if
385    the DHCP client identifier option is being used, the first byte of
386    the DHCID RR should be zero, and the second byte should be 61
387    decimal. The rest of the DHCID RR MUST contain the results of
388    computing a one-way hash across the payload of the option being
389    used, using the MD5 algorithm. The payload of a DHCP option consists
390    of the bytes of the option following the option code and length.
392    In order for independent DHCP implementations to be able to use the
393    DHCID RR as a prerequisite in dynamic DNS updates, each updater must
394    be able to reliably choose the same identifier that any other would
395    choose.  To make this possible, we specify a prioritization which
398 Stapp & Rekhter          Expires September 2000                 [Page 7]
400 Internet-Draft      Interaction between DHCP and DNS          March 2000
403    will ensure that for any given DHCP client request, any updater will
404    select the same client-identity data.  All updaters MUST use this
405    order of prioritization by default, but all implementations SHOULD
406    be configurable to use a different prioritization if so desired by
407    the site administrators.  Because of the possibility of future
408    changes in the DHCP protocol, implementors SHOULD check for updated
409    versions of this draft when implementing new DHCP clients and
410    servers which can perform DDNS updates, and also when releasing new
411    versions of existing clients and servers.
413    DHCP clients and servers should use the following forms of client
414    identification, starting with the most preferable, and finishing
415    with the least preferable.  If the client does not send any of these
416    forms of identification, the DHCP/DDNS interaction is not defined by
417    this specification.  The most preferable form of identification is
418    the Globally Unique Identifier Option [TBD].  Next is the DHCP
419    Client Identifier option.  Last is the client's link-layer address,
420    as conveyed in its DHCPREQUEST message.  Implementors should note
421    that the link-layer address cannot be used if there are no
422    significant bytes in the chaddr field of the DHCP client's request,
423    because this does not constitute a unique identifier.
425 4.4 DNS RR TTLs
427    RRs associated with DHCP clients may be more volatile than
428    statically configured RRs. DHCP clients and servers which perform
429    dynamic updates should attempt to specify resource record TTLs which
430    reflect this volatility, in order to minimize the possibility that
431    there will be stale records in resolvers' caches. A reasonable basis
432    for RR TTLs is the lease duration itself: TTLs of 1/2 or 1/3 the
433    expected lease duration might be reasonable defaults. Because
434    configured DHCP lease times vary widely from site to site, it may
435    also be desirable to establish a fixed TTL ceiling. DHCP clients and
436    servers MAY allow administrators to configure the TTLs they will
437    supply, possibly as a fraction of the actual lease time, or as a
438    fixed value.
440 5. Client FQDN Option
442    To update the IP address to FQDN mapping a DHCP server needs to know
443    the FQDN of the client to which the server leases the address. To
444    allow the client to convey its FQDN to the server this document
445    defines a new DHCP option, called "Client FQDN". The FQDN Option
446    also contains Flags and RCode fields which DHCP servers can use to
447    convey information about DNS updates to clients. 
449    Clients MAY send the FQDN option, setting appropriate Flags values,
450    in both their DISCOVER and REQUEST messages. If a client sends the
451    FQDN option in its DISCOVER message, it MUST send the option in
454 Stapp & Rekhter          Expires September 2000                 [Page 8]
456 Internet-Draft      Interaction between DHCP and DNS          March 2000
459    subsequent REQUEST messages. 
461    The code for this option is 81. Its minimum length is 4.
464         Code   Len    Flags  RCODE1 RCODE2   Domain Name
465        +------+------+------+------+------+------+--
466        |  81  |   n  |      |      |      |       ...
467        +------+------+------+------+------+------+--
470 5.1 The Flags Field
473         0 1 2 3 4 5 6 7
474        +-+-+-+-+-+-+-+-+
475        |   MBZ   |E|O|S|
476        +-+-+-+-+-+-+-+-+
479    When a DHCP client sends the FQDN option in its DHCPDISCOVER and/or
480    DHCPREQUEST messages, it sets the right-most bit (labelled "S") to
481    indicate that it will not perform any Dynamic DNS updates, and that
482    it expects the DHCP server to perform any FQDN-to-IP (the A RR) DNS
483    update on its behalf. If this bit is clear, the client indicates
484    that it intends to maintain its own FQDN-to-IP mapping update. 
486    If a DHCP server intends to take responsibility for the A RR update
487    whether or not the client sending the FQDN option has set the "S"
488    bit, it sets both the "O" bit and the "S" bit, and sends the FQDN
489    option in its DHCPOFFER and/or DHCPACK messages. 
491    The data in the Domain Name field may appear in one of two formats:
492    ASCII, or DNS-style binary encoding (without compression, of
493    course), as described in RFC1035[2]. A client which sends the FQDN
494    option MUST set the "E" bit to indicate that the data in the Domain
495    Name field is DNS binary encoded. If a server receives an FQDN
496    option from a client, and intends to include an FQDN option in its
497    reply, it MUST use the same encoding that the client used. The DNS
498    encoding is recommended. The use of ASCII-encoded domain-names is
499    fragile, and the use of ASCII encoding in this option should be
500    considered deprecated. 
502    The remaining bits in the Flags field are reserved for future
503    assignment. DHCP clients and servers which send the FQDN option MUST
504    set the MBZ bits to 0, and they MUST ignore values in the part of
505    the field labelled "MBZ". 
510 Stapp & Rekhter          Expires September 2000                 [Page 9]
512 Internet-Draft      Interaction between DHCP and DNS          March 2000
515 5.2 The RCODE Fields
517    The RCODE1 and RCODE2 fields are used by a DHCP server to indicate
518    to a DHCP client the Response Code from any A or PTR RR Dynamic DNS
519    Updates it has performed. The server may also use these fields to
520    indicate whether it has attempted such an update before sending the
521    DHCPACK message. Each of these fields is one byte long.
523    Implementors should note that EDNS0 describes a mechanism for
524    extending the length of a DNS RCODE to 12 bits. EDNS0 is specified
525    in RFC2671[8]. Only the least-significant 8 bits of the RCODE from a
526    Dynamic DNS Update will be carried in the Client FQDN DHCP Option.
527    This provides enough number space to accomodate the RCODEs defined
528    in the Dynamic DNS Update specification.
530 5.3 The Domain Name Field
532    The Domain Name part of the option carries all or part of the FQDN
533    of a DHCP client. A client may be configured with a fully-qualified
534    domain name, or with a partial name that is not fully-qualified. If
535    a client knows only part of its name, it MAY send a single label,
536    indicating that it knows part of the name but does not necessarily
537    know the zone in which the name is to be embedded. The data in the
538    Domain Name field may appear in one of two formats: ASCII (with no
539    terminating NULL), or DNS encoding as specified in RFC1035[2]. If
540    the DHCP client wishes to use DNS encoding, it MUST set the
541    third-from-rightmost bit in the Flags field (the "E" bit); if it
542    uses ASCII encoding, it MUST clear the "E" bit.
544    A DHCP client that can only send a single label using ASCII encoding
545    includes a series of ASCII characters in the Domain Name field,
546    excluding the "." (dot) character. The client SHOULD follow the
547    character-set recommendations of RFC1034[1] and RFC1035[2]. A client
548    using DNS binary encoding which wants to suggest part of its FQDN
549    MAY send a non-terminal sequence of labels in the Domain Name part
550    of the option.
552 6. DHCP Client behavior
554    The following describes the behavior of a DHCP client that
555    implements the Client FQDN option.
557    If a client that owns/maintains its own FQDN wants to be responsible
558    for updating the FQDN to IP address mapping for the FQDN and
559    address(es) used by the client, then the client MUST include the
560    Client FQDN option in the DHCPREQUEST message originated by the
561    client. A DHCP client MAY choose to include the Client FQDN option
562    in its DISCOVER messages as well as its REQUEST messages. The
563    rightmost ("S") bit in the Flags field in the option MUST be set to
566 Stapp & Rekhter          Expires September 2000                [Page 10]
568 Internet-Draft      Interaction between DHCP and DNS          March 2000
571    0. Once the client's DHCP configuration is completed (the client
572    receives a DHCPACK message, and successfully completes a final check
573    on the parameters passed in the message), the client MAY originate
574    an update for the A RR (associated with the client's FQDN). The
575    update MUST be originated following the procedures described in
576    RFC2136[5] and Section 8. If the DHCP server from which the client
577    is requesting a lease includes the FQDN option in its ACK message,
578    and if the server sets both the "S" and the "O" bits (the two
579    rightmost bits) in the option's flags field, the DHCP client MUST
580    NOT initiate an update for the name in the Domain Name field.
582    A client can choose to delegate the responsibility for updating the
583    FQDN to IP address mapping for the FQDN and address(es) used by the
584    client to the server.  In order to inform the server of this choice,
585    the client SHOULD include the Client FQDN option in its DHCPREQUEST
586    message. The rightmost (or "S") bit in the Flags field in the option
587    MUST be set to 1. A client which delegates this responsibility MUST
588    NOT attempt to perform a Dynamic DNS update for the name in the
589    Domain Name field of the FQDN option. The client MAY supply an FQDN
590    in the Client FQDN option, or it MAY supply a single label (the
591    most-specific label), or it MAY leave that field empty as a signal
592    to the server to generate an FQDN for the client in any manner the
593    server chooses.
595    Since there is a possibility that the DHCP server may be configured
596    to complete or replace a domain name that the client was configured
597    to send, the client might find it useful to send the FQDN option in
598    its DISCOVER messages. If the DHCP server returns different Domain
599    Name data in its OFFER message, the client could use that data in
600    performing its own eventual A RR update, or in forming the FQDN
601    option that it sends in its REQUEST message. There is no requirement
602    that the client send identical FQDN option data in its DISCOVER and
603    REQUEST messages. In particular, if a client has sent the FQDN
604    option to its server, and the configuration of the client changes so
605    that its notion of its domain name changes, it MAY send the new name
606    data in an FQDN option when it communicates with the server again.
607    This may allow the DHCP server to update the name associated with
608    the PTR record, and, if the server updated the A record representing
609    the client, to delete that record and attempt an update for the
610    client's current domain name.
612    A client that delegates the responsibility for updating the FQDN to
613    IP address mapping to a server might not receive any indication
614    (either positive or negative) from the server whether the server was
615    able to perform the update. In this case the client MAY use a DNS
616    query to check whether the mapping is updated.
618    A client MUST set the RCODE1 and RCODE2 fields in the Client FQDN
619    option to 0 when sending the option.
622 Stapp & Rekhter          Expires September 2000                [Page 11]
624 Internet-Draft      Interaction between DHCP and DNS          March 2000
627    If a client releases its lease prior to the lease expiration time
628    and the client is responsible for updating its A RR, the client
629    SHOULD delete the A RR (following the procedures described in
630    Section 8) associated with the leased address before sending a DHCP
631    RELEASE message. Similarly, if a client was responsible for updating
632    its A RR, but is unable to renew its lease, the client SHOULD
633    attempt to delete the A RR before its lease expires. A DHCP client
634    which has not been able to delete an A RR which it added (because it
635    has lost the use of its DHCP IP address) should attempt to notify
636    its administrator.
638 7. DHCP Server behavior
640    When a server receives a DHCPREQUEST message from a client, if the
641    message contains the Client FQDN option, and the server replies to
642    the message with a DHCPACK message, the server may be configured to
643    originate an update for the PTR RR (associated with the address
644    leased to the client). Any such update MUST be originated following
645    the procedures described in Section 8. The server MAY complete the
646    update before the server sends the DHCPACK message to the client. In
647    this case the RCODE from the update MUST be carried to the client in
648    the RCODE1 field of the Client FQDN option in the DHCPACK message.
649    Alternatively, the server MAY send the DHCPACK message to the client
650    without waiting for the update to be completed. In this case the
651    RCODE1 field of the Client FQDN option in the DHCPACK message MUST
652    be set to 255.  The choice between the two alternatives is entirely
653    determined by the configuration of the DHCP server. Servers SHOULD
654    support both configuration options.
656    When a server receives a DHCPREQUEST message containing the Client
657    FQDN option, the server MUST ignore the values carried in the RCODE1
658    and RCODE2 fields of the option.
660    In addition, if the Client FQDN option carried in the DHCPREQUEST
661    message has the "S" bit in its Flags field set, then the server MAY
662    originate an update for the A RR (associated with the FQDN carried
663    in the option) if it is configured to do so by the site's
664    administrator, and if it has the necessary credentials. The server
665    MAY be configured to use the name supplied in the client's FQDN
666    option, or it MAY be configured to modify the supplied name, or
667    substitute a different name.
669    Any such update MUST be originated following the procedures
670    described in Section 8. The server MAY originate the update before
671    the server sends the DHCPACK message to the client. In this case the
672    RCODE from the update [RFC2136] MUST be carried to the client in the
673    RCODE2 field of the Client FQDN option in the DHCPACK message. 
674    Alternatively the server MAY send the DHCPACK message to the client
675    without waiting for the update to be completed. In this case the
678 Stapp & Rekhter          Expires September 2000                [Page 12]
680 Internet-Draft      Interaction between DHCP and DNS          March 2000
683    RCODE2 field of the Client FQDN option in the DHCPACK message MUST
684    be set to 255. The choice between the two alternatives is entirely
685    up to the DHCP server. In either case, if the server intends to
686    perform the DNS update and the client's REQUEST message included the
687    FQDN option, the server SHOULD include the FQDN option in its ACK
688    message, and MUST set the "S" bit in the option's Flags field.
690    Even if the Client FQDN option carried in the DHCPREQUEST message
691    has the "S" bit in its Flags field clear (indicating that the client
692    wants to update the A RR), the server MAY be configured by the local
693    administrator to update the A RR on the client's behalf. A server
694    which is configured to override the client's preference SHOULD
695    include an FQDN option in its ACK message, and MUST set both the "O"
696    and "S" bits in the FQDN option's Flags field. The update MUST be
697    originated following the procedures described in Section 8. The
698    server MAY originate the update before the server sends the DHCPACK
699    message to the client. In this case the RCODE from the update
700    [RFC2136] MUST be carried to the client in the RCODE2 field of the
701    Client FQDN option in the DHCPACK message. Alternatively, the server
702    MAY send the DHCPACK message to the client without waiting for the
703    update to be completed. In this case the RCODE2 field of the Client
704    FQDN option in the DHCPACK message MUST be set to 255. Whether the
705    DNS update occurs before or after the DHCPACK is sent is entirely up
706    to the DHCP server's configuration.
708    When a DHCP server sends the Client FQDN option to a client in the
709    DHCPACK message, the DHCP server SHOULD send its notion of the
710    complete FQDN for the client in the Domain Name field. The server
711    MAY simply copy the Domain Name field from the Client FQDN option
712    that the client sent to the server in the DHCPREQUEST message. The
713    DHCP server MAY be configured to complete or modify the domain name
714    which a client sent, or it MAY be configured to substitute a
715    different name. If the server initiates a DDNS update which is not
716    complete until after the server has replied to the DHCP client, the
717    server's The server MUST use the same encoding format (ASCII or DNS
718    binary encoding) that the client used in the FQDN option in its
719    DHCPREQUEST, and MUST set the "E" bit in the option's Flags field
720    accordingly.
722    If a client's DHCPREQUEST message doesn't carry the Client FQDN
723    option (e.g., the client doesn't implement the Client FQDN option),
724    the server MAY be configured to update either or both of the A and
725    PTR RRs. The updates MUST be originated following the procedures
726    described in Section 8.
728    If a server detects that a lease on an address that the server
729    leases to a client has expired, the server SHOULD delete any PTR RR
730    which it added via dynamic update. In addition, if the server added
731    an A RR on the client's behalf, the server SHOULD also delete the A
734 Stapp & Rekhter          Expires September 2000                [Page 13]
736 Internet-Draft      Interaction between DHCP and DNS          March 2000
739    RR. The deletion MUST follow the procedures described in Section 8.
741    If a server terminates a lease on an address prior to the lease's
742    expiration time, for instance by sending a DHCPNAK to a client, the
743    server SHOULD delete any PTR RR which it associated with the address
744    via DNS Dynamic Update. In addition, if the server took
745    responsibility for an A RR, the server SHOULD also delete that A RR.
746    The deletion MUST follow the procedures described in Section 8.
748 8. Procedures for performing DNS updates
750 8.1 Adding A RRs to DNS
752    When a DHCP client or server intends to update an A RR, it first
753    prepares a DNS UPDATE query which includes as a prerequisite the
754    assertion that the name does not exist.  The update section of the
755    query attempts to add the new name and its IP address mapping (an A
756    RR), and the DHCID RR with its unique client-identity.
758    If this update operation succeeds, the updater can conclude that it
759    has added a new name whose only RRs are the A and DHCID RR records.
760    The A RR update is now complete (and a client updater is finished,
761    while a server might proceed to perform a PTR RR update).
763    If the first update operation fails with YXDOMAIN, the updater can
764    conclude that the intended name is in use.  The updater then
765    attempts to confirm that the DNS name is not being used by some
766    other host. The updater prepares a second UPDATE query in which the
767    prerequisite is that the desired name has attached to it a DHCID RR
768    whose contents match the client identity.  The update section of
769    this query deletes the existing A records on the name, and adds the
770    A record that matches the DHCP binding and the DHCID RR with the
771    client identity.
773    If this query succeeds, the updater can conclude that the current
774    client was the last client associated with the domain name, and that
775    the name now contains the updated A RR. The A RR update is now
776    complete (and a client updater is finished, while a server would
777    then proceed to perform a PTR RR update).
779    If the second query fails with NXRRSET, the updater must conclude
780    that the client's desired name is in use by another host.  At this
781    juncture, the updater can decide (based on some administrative
782    configuration outside of the scope of this document) whether to let
783    the existing owner of the name keep that name, and to (possibly)
784    perform some name disambiguation operation on behalf of the current
785    client, or to replace the RRs on the name with RRs that represent
786    the current client. If the configured policy allows replacement of
787    existing records, the updater submits a query that deletes the
790 Stapp & Rekhter          Expires September 2000                [Page 14]
792 Internet-Draft      Interaction between DHCP and DNS          March 2000
795    existing A RR and the existing DHCID RR, adding A and DHCID RRs that
796    represent the IP address and client-identity of the new client.
797       
799       DISCUSSION:
800       The updating entity may be configured to allow the existing DNS
801       records on the domain name to remain unchanged, and to perform
802       disambiguation on the name of the current client in order to
803       attempt to generate a similar but unique name for the current
804       client. In this case, once another candidate name has been
805       generated, the updater should restart the process of adding an A
806       RR as specified in this section.
808 8.2 Adding PTR RR Entries to DNS
810    The DHCP server submits a DNS query which deletes all of the PTR RRs
811    associated with the lease IP address, and adds a PTR RR whose data
812    is the client's (possibly disambiguated) host name. The server also
813    adds a DHCID RR specified in Section 4.3.
815 8.3 Removing Entries from DNS
817    The most important consideration in removing DNS entries is be sure
818    that an entity removing a DNS entry is only removing an entry that
819    it added, or for which an administrator has explicitly assigned it
820    responsibility.
822    When a lease expires or a DHCP client issues a DHCPRELEASE request,
823    the DHCP server SHOULD delete the PTR RR that matches the DHCP
824    binding, if one was successfully added. The server's update query
825    SHOULD assert that the name in the PTR record matches the name of
826    the client whose lease has expired or been released.
828    The entity chosen to handle the A record for this client (either the
829    client or the server) SHOULD delete the A record that was added when
830    the lease was made to the client.
832    In order to perform this delete, the updater prepares an UPDATE
833    query which contains two prerequisites.  The first prerequisite
834    asserts that the DHCID RR exists whose data is the client identity
835    described in Section 4.3. The second prerequisite asserts that the
836    data in the A RR contains the IP address of the lease that has
837    expired or been released.
839    If the query fails, the updater MUST NOT delete the DNS name.  It
840    may be that the host whose lease on the server has expired has moved
841    to another network and obtained a lease from a different server,
842    which has caused the client's A RR to be replaced. It may also be
843    that some other client has been configured with a name that matches
844    the name of the DHCP client, and the policy was that the last client
847 Stapp & Rekhter          Expires September 2000                [Page 15]
849 Internet-Draft      Interaction between DHCP and DNS          March 2000
852    to specify the name would get the name.  In this case, the DHCID RR
853    will no longer match the updater's notion of the client-identity of
854    the host pointed to by the DNS name.
856 8.4 Updating other RRs
858    The procedures described in this document only cover updates to the
859    A and PTR RRs. Updating other types of RRs is outside the scope of
860    this document.
862 9. Security Considerations
864    Unauthenticated updates to the DNS can lead to tremendous confusion,
865    through malicious attack or through inadvertent misconfiguration.
866    Administrators should be wary of permitting unsecured DNS updates to
867    zones which are exposed to the global Internet. Both DHCP clients
868    and servers SHOULD use some form of update request origin
869    authentication procedure (e.g., Simple Secure DNS Update[11]) when
870    performing DNS updates.
872    Whether a DHCP client may be responsible for updating an FQDN to IP
873    address mapping, or whether this is the responsibility of the DHCP
874    server is a site-local matter. The choice between the two
875    alternatives may be based on the security model that is used with
876    the Dynamic DNS Update protocol (e.g., only a client may have
877    sufficient credentials to perform updates to the FQDN to IP address
878    mapping for its FQDN).
880    Whether a DHCP server is always responsible for updating the FQDN to
881    IP address mapping (in addition to updating the IP to FQDN mapping),
882    regardless of the wishes of an individual DHCP client, is also a
883    site-local matter. The choice between the two alternatives may be
884    based on the security model that is being used with dynamic DNS
885    updates. In cases where a DHCP server is performing DNS updates on
886    behalf of a client, the DHCP server should be sure of the DNS name
887    to use for the client, and of the identity of the client.
889    Currently, it is difficult for DHCP servers to develop much
890    confidence in the identities of its clients, given the absence of
891    entity authentication from the DHCP protocol itself. There are many
892    ways for a DHCP server to develop a DNS name to use for a client,
893    but only in certain relatively unusual circumstances will the DHCP
894    server know for certain the identity of the client. If DHCP
895    Authentication[10] becomes widely deployed this may become more
896    customary.
898    One example of a situation which offers some extra assurances is one
899    where the DHCP client is connected to a network through an MCNS
900    cable modem, and the CMTS (head-end) of the cable modem ensures that
903 Stapp & Rekhter          Expires September 2000                [Page 16]
905 Internet-Draft      Interaction between DHCP and DNS          March 2000
908    MAC address spoofing simply does not occur. Another example of a
909    configuration that might be trusted is one where clients obtain
910    network access via a network access server using PPP. The NAS itself
911    might be obtaining IP addresses via DHCP, encoding a client
912    identification into the DHCP client-id option.  In this case, the
913    network access server as well as the DHCP server might be operating
914    within a trusted environment, in which case the DHCP server could be
915    configured to trust that the user authentication and authorization
916    procedure of the remote access server was sufficient, and would
917    therefore trust the client identification encoded within the DHCP
918    client-id.
920 10. Acknowledgements
922    Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter
923    Ford, Edie Gunter, Andreas Gustafsson, R. Barr Hibbs, Kim Kinnear,
924    Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Josh Littlefield,
925    Michael Patton, and Glenn Stump for their review and comments.
927 References
929    [1]  Mockapetris, P., "Domain names - Concepts and Facilities", RFC
930         1034, Nov 1987.
932    [2]  Mockapetris, P., "Domain names - Implementation and
933         Specification", RFC 1035, Nov 1987.
935    [3]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
936         March 1997.
938    [4]  Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and
939         Answers to Commonly asked ``New Internet User'' Questions", RFC
940         1594, March 1994.
942    [5]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
943         Updates in the Domain Name System", RFC 2136, April 1997.
945    [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
946         Levels", RFC 2119, March 1997.
948    [7]  Eastlake, D., "Domain Name System Security Extensions", RFC
949         2535, March 1999.
951    [8]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
952         August 1999.
954    [9]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
955         "Secret Key Transaction Authentication for DNS (TSIG)
956         (draft-ietf-dnsext-tsig-*)", July 1999.
959 Stapp & Rekhter          Expires September 2000                [Page 17]
961 Internet-Draft      Interaction between DHCP and DNS          March 2000
964    [10]  Droms, R. and W. Arbaugh, "Authentication for DHCP Messages
965          (draft-ietf-dhc-authentication-*)", June 1999.
967    [11]  Wellington, B., "Simple Secure DNS Dynamic Updates
968          (draft-ietf-dnsext-simple-secure-update-*)", June 1999.
970    [12]  Gustafsson, A., "A DNS RR for encoding DHCP client identity
971          (draft-ietf-dnsext-dhcid-rr-*)", October 1999.
973    [13]  Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
974          April 1992.
976 Authors' Addresses
978    Mark Stapp
979    Cisco Systems, Inc.
980    250 Apollo Dr.
981    Chelmsford, MA  01824
982    US
984    Phone: 978.244.8498
985    EMail: mjs@cisco.com
987    Yakov Rekhter
988    Cisco Systems, Inc.
989    170 Tasman Dr.
990    San Jose, CA  95134
991    US
993    Phone: 914.235.2128
994    EMail: yakov@cisco.com
1015 Stapp & Rekhter          Expires September 2000                [Page 18]
1017 Internet-Draft      Interaction between DHCP and DNS          March 2000
1020 Full Copyright Statement
1022    Copyright (C) The Internet Society (2000). All Rights Reserved.
1024    This document and translations of it may be copied and furnished to
1025    others, and derivative works that comment on or otherwise explain it
1026    or assist in its implmentation may be prepared, copied, published
1027    and distributed, in whole or in part, without restriction of any
1028    kind, provided that the above copyright notice and this paragraph
1029    are included on all such copies and derivative works. However, this
1030    document itself may not be modified in any way, such as by removing
1031    the copyright notice or references to the Internet Society or other
1032    Internet organizations, except as needed for the purpose of
1033    developing Internet standards in which case the procedures for
1034    copyrights defined in the Internet Standards process must be
1035    followed, or as required to translate it into languages other than
1036    English.
1038    The limited permissions granted above are perpetual and will not be
1039    revoked by the Internet Society or its successors or assigns.
1041    This document and the information contained herein is provided on an
1042    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1043    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1044    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1045    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1046    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1048 Acknowledgement
1050    Funding for the RFC editor function is currently provided by the
1051    Internet Society.
1071 Stapp & Rekhter          Expires September 2000                [Page 19]