draft-ietf-dhc-ddns-resolution-02.txt   draft-ietf-dhc-ddns-resolution-03.txt 
DHC Working Group M. Stapp DHC Working Group M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: January 18, 2002 July 20, 2001 Expires: May 22, 2002 November 21, 2001
Resolution of DNS Name Conflicts Among DHCP Clients Resolution of DNS Name Conflicts Among DHCP Clients
<draft-ietf-dhc-ddns-resolution-02.txt> <draft-ietf-dhc-ddns-resolution-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 18, 2002. This Internet-Draft will expire on May 22, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
DHCP provides a powerful mechanism for IP host configuration. DHCP provides a powerful mechanism for IP host configuration.
However, the configuration capability provided by DHCP does not However, the configuration capability provided by DHCP does not
include updating DNS(RFC1034[1], RFC1035[2]), and specifically include updating DNS(RFC1034[1], RFC1035[2]), and specifically
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Issues with DNS Update in DHCP Environments . . . . . . . . . 3 3. Issues with DNS Update in DHCP Environments . . . . . . . . . 3
3.1 Client Mis-Configuration . . . . . . . . . . . . . . . . . . . 4 3.1 Client Mis-Configuration . . . . . . . . . . . . . . . . . . . 4
3.2 Multiple DHCP Servers . . . . . . . . . . . . . . . . . . . . 4 3.2 Multiple DHCP Servers . . . . . . . . . . . . . . . . . . . . 4
4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 5 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 5
4.1 Format of the DHCID RRDATA . . . . . . . . . . . . . . . . . . 6 4.1 Format of the DHCID RRDATA . . . . . . . . . . . . . . . . . . 6
5. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Procedures for performing DNS updates . . . . . . . . . . . . 8 6. Procedures for performing DNS updates . . . . . . . . . . . . 8
6.1 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . . 8 6.1 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . . 8
6.2 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . . 9 6.2 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . . 9
6.3 Removing Entries from DNS . . . . . . . . . . . . . . . . . . 9 6.3 Removing Entries from DNS . . . . . . . . . . . . . . . . . . 9
6.4 Updating Other RRs . . . . . . . . . . . . . . . . . . . . . . 10 6.4 Updating Other RRs . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 4, line 9 skipping to change at page 4, line 9
use the term "Name Conflict" to refer to cases where more than one use the term "Name Conflict" to refer to cases where more than one
DHCP client wishes to be associated with a single FQDN. This DHCP client wishes to be associated with a single FQDN. This
specification describes a mechanism designed to allow updaters to specification describes a mechanism designed to allow updaters to
detect these situations, and suggests that DHCP implementations use detect these situations, and suggests that DHCP implementations use
this mechanism by default. this mechanism by default.
3.1 Client Mis-Configuration 3.1 Client Mis-Configuration
At many (though not all) sites, administrators wish to maintain a At many (though not all) sites, administrators wish to maintain a
one-to-one relationship between active DHCP clients and domain one-to-one relationship between active DHCP clients and domain
names, and to maintain consistency between the a host's A and PTR names, and to maintain consistency between a host's A and PTR RRs.
RRs. Hosts which are not represented in the DNS, or hosts which Hosts which are not represented in the DNS, or hosts which
inadvertently share an FQDN with another host may encounter inadvertently share an FQDN with another host may encounter
inconsistent behavior or may not be able to obtain access to network inconsistent behavior or may not be able to obtain access to network
resources. Whether each DHCP client is configured with a domain name resources. Whether each DHCP client is configured with a domain name
by its administrator or whether the DHCP server is configured to by its administrator or whether the DHCP server is configured to
distribute the clients' names, the consistency of the DNS data is distribute the clients' names, the consistency of the DNS data is
entirely dependent on the accuracy of the configuration procedure. entirely dependent on the accuracy of the configuration procedure.
Sites which use Secure DNS[9] may configure credentials for each Sites which use Secure DNS[9] may configure credentials for each
host and its assigned name in a way that is more error-resistant, host and its assigned name in a way that is more error-resistant,
but this level of pre-configuration is still rare in DHCP but this level of pre-configuration is still rare in DHCP
environments. environments.
skipping to change at page 5, line 33 skipping to change at page 5, line 33
If the servers cannot distinguish between these situations, they If the servers cannot distinguish between these situations, they
cannot enforce the site's naming policies. cannot enforce the site's naming policies.
4. Use of the DHCID RR 4. Use of the DHCID RR
A solution to both of these problems is for the updater (a DHCP A solution to both of these problems is for the updater (a DHCP
client or DHCP server) to be able to determine which DHCP client has client or DHCP server) to be able to determine which DHCP client has
been associated with a DNS name, in order to offer administrators been associated with a DNS name, in order to offer administrators
the opportunity to configure updater behavior. the opportunity to configure updater behavior.
FOr this purpose, a DHCID RR, described in [6], is used to associate For this purpose, a DHCID RR, described in [6], is used to associate
client identification information with a DNS name and the A or PTR client identification information with a DNS name and the A or PTR
RR associated with that name. When either a client or server adds an RR associated with that name. When either a client or server adds an
A or PTR RR for a client, it also adds a DHCID RR which specifies a A or PTR RR for a client, it also adds a DHCID RR which specifies a
unique client identity (based on a "client specifier" created from unique client identity (based on a "client specifier" created from
the data in the client's DHCPREQUEST message). In this model, only the data in the client's DHCPREQUEST message). In this model, only
one A RR is associated with a given DNS name at a time. one A RR is associated with a given DNS name at a time.
By associating this ownership information with each DNS name, By associating this ownership information with each DNS name,
cooperating DNS updaters may determine whether their client is cooperating DNS updaters may determine whether their client is
currently associated with a particular DNS name and implement the currently associated with a particular DNS name and implement the
skipping to change at page 7, line 44 skipping to change at page 7, line 44
changes in the DHCP protocol, implementors SHOULD check for updated changes in the DHCP protocol, implementors SHOULD check for updated
versions of this specification when implementing new DHCP clients versions of this specification when implementing new DHCP clients
and servers which can perform DNS updates, and also when releasing and servers which can perform DNS updates, and also when releasing
new versions of existing clients and servers. new versions of existing clients and servers.
DHCP clients and servers should use the following forms of client DHCP clients and servers should use the following forms of client
identification, starting with the most preferable, and finishing identification, starting with the most preferable, and finishing
with the least preferable. If the client does not send any of these with the least preferable. If the client does not send any of these
forms of identification, the DHCP/DNS interaction is not defined by forms of identification, the DHCP/DNS interaction is not defined by
this specification. The most preferable form of identification is this specification. The most preferable form of identification is
the Globally Unique Identifier Option [TBD]. Next is the DHCP the DHCP Client Identifier option. Last is the client's link-layer
Client Identifier option. Last is the client's link-layer address, address, as conveyed in its DHCPREQUEST message. Implementors
as conveyed in its DHCPREQUEST message. Implementors should note should note that the link-layer address cannot be used if there are
that the link-layer address cannot be used if there are no no significant bytes in the chaddr field of the DHCP client's
significant bytes in the chaddr field of the DHCP client's request, request, because this does not constitute a unique identifier.
because this does not constitute a unique identifier.
5. DNS RR TTLs 5. DNS RR TTLs
RRs associated with DHCP clients may be more volatile than RRs associated with DHCP clients may be more volatile than
statically configured RRs. DHCP clients and servers which perform statically configured RRs. DHCP clients and servers which perform
dynamic updates should attempt to specify resource record TTLs which dynamic updates should attempt to specify resource record TTLs which
reflect this volatility, in order to minimize the possibility that reflect this volatility, in order to minimize the possibility that
there will be stale records in resolvers' caches. A reasonable basis 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 for RR TTLs is the lease duration itself: TTLs of 1/2 or 1/3 the
expected lease duration might be reasonable defaults. Because expected lease duration might be reasonable defaults. Because
configured DHCP lease times vary widely from site to site, it may configured DHCP lease times vary widely from site to site, it may
also be desirable to establish a fixed TTL ceiling. DHCP clients and also be desirable to establish a fixed TTL ceiling. DHCP clients and
servers MAY allow administrators to configure the TTLs they will servers MAY allow administrators to configure the TTLs they will
supply, possibly as a fraction of the actual lease time, or as a supply, possibly as a fraction of the actual lease time, or as a
fixed value. fixed value. In general, the TTLs of RRs added as a result of DHCP
lease activity SHOULD be less than the initial lease time.
6. Procedures for performing DNS updates 6. Procedures for performing DNS updates
6.1 Adding A RRs to DNS 6.1 Adding A RRs to DNS
When a DHCP client or server intends to update an A RR, it first 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 prepares a DNS UPDATE query which includes as a prerequisite the
assertion that the name does not exist. The update section of 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 query attempts to add the new name and its IP address mapping (an A
RR), and the DHCID RR with its unique client-identity. RR), and the DHCID RR with its unique client-identity.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/