draft-ietf-dhc-ddns-resolution-00.txt   draft-ietf-dhc-ddns-resolution-01.txt 
DHC Working Group M. Stapp DHC Working Group M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: January 12, 2001 July 14, 2000 Expires: August 31, 2001 March 2, 2001
Resolution of DNS Name Conflicts Among DHCP Clients Resolution of DNS Name Conflicts Among DHCP Clients
<draft-ietf-dhc-ddns-resolution-00.txt> <draft-ietf-dhc-ddns-resolution-01.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 12, 2001. This Internet-Draft will expire on August 31, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). 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
updating the name to address and address to name mappings maintained updating the name to address and address to name mappings maintained
in the DNS. in the DNS.
The "Client FQDN Option"[14] specifies the client FQDN option, The "Client FQDN Option"[13] specifies the client FQDN option,
through which DHCP clients and servers can exchange information through which DHCP clients and servers can exchange information
about client FQDNs. This document describes techniques for the about client FQDNs. This document describes techniques for the
resolution of DNS name conflicts among DHCP clients. resolution of DNS name conflicts among DHCP clients.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Issues with DDNS in DHCP Environments . . . . . . . . . . . 3 3. Issues with DDNS in DHCP Environments . . . . . . . . . . . 3
3.1 Name Conflicts . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Name Conflicts . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Multiple DHCP servers . . . . . . . . . . . . . . . . . . . 4 3.2 Multiple DHCP servers . . . . . . . . . . . . . . . . . . . 5
3.3 Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 5 3.3 Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 5
3.3.1 Format of the DHCID RRDATA . . . . . . . . . . . . . . . . . 5 3.3.1 Format of the DHCID RRDATA . . . . . . . . . . . . . . . . . 5
3.4 DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Procedures for performing DNS updates . . . . . . . . . . . 7 4. Procedures for performing DNS updates . . . . . . . . . . . 7
4.1 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . 7 4.1 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . 7
4.2 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . 8 4.2 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . 8
4.3 Removing Entries from DNS . . . . . . . . . . . . . . . . . 8 4.3 Removing Entries from DNS . . . . . . . . . . . . . . . . . 9
4.4 Updating other RRs . . . . . . . . . . . . . . . . . . . . . 9 4.4 Updating other RRs . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119[6]. document are to be interpreted as described in RFC 2119[6].
2. Introduction 2. Introduction
"The Client FQDN Option"[14] includes a description of the operation "The Client FQDN Option"[13] includes a description of the operation
of DHCP[3] clients and servers that use the client FQDN option. of DHCP[3] clients and servers that use the client FQDN option.
Through the use of the client FQDN option, DHCP clients and servers Through the use of the client FQDN option, DHCP clients and servers
can negotiate the client's FQDN and the allocation of responsibility can negotiate the client's FQDN and the allocation of responsibility
for updating the DHCP client's A RR record. This document for updating the DHCP client's A RR. This document identifies
identifies situations in which conflicts in the use of FQDNs may situations in which conflicts in the use of FQDNs may arise among
arise among DHCP clients, and describes a strategy for the use of DHCP clients, and describes a strategy for the use of the DHCID DNS
the DHCID DNS resource record[12] in resolving those conflicts. resource record[11] in resolving those conflicts.
In any case, whether a site permits all, some, or no DHCP servers
and clients to perform DNS updates into the zones which it controls
is entirely a matter of local administrative policy. This document
does not require any specific administrative policy, and does not
propose one. The range of possible policies is very broad, from
sites where only the DHCP servers have been given credentials that
the DNS servers will accept, to sites where each individual DHCP
client has been configured with credentials which allow the client
to modify its own domain name. Compliant implementations MAY support
some or all of these possibilities. Furthermore, this specification
applies only to DHCP client and server processes: it does not apply
to other processes which initiate DNS updates.
3. Issues with DDNS in DHCP Environments 3. Issues with DDNS in DHCP Environments
There are two DNS update situations that require special There are two DNS update situations that require special
consideration in DHCP environments: cases where more than one DHCP consideration in DHCP environments: cases where more than one DHCP
client has been configured with the same FQDN, and cases where more client has been configured with the same FQDN, and cases where more
than one DHCP server has been given authority to perform DNS updates than one DHCP server has been given authority to perform DNS updates
in a zone. In these cases, it is possible for DNS records to be in a zone. In these cases, it is possible for DNS records to be
modified in inconsistent ways unless the updaters have a mechanism modified in inconsistent ways unless the updaters have a mechanism
that allows them to detect anomolous situations. If DNS updaters can that allows them to detect anomolous situations. If DNS updaters can
skipping to change at page 5, line 12 skipping to change at page 5, line 27
to provide reasonable and consistent DNS name update behavior for to provide reasonable and consistent DNS name update behavior for
DHCP clients. DHCP clients.
3.3 Use of the DHCID RR 3.3 Use of the DHCID RR
A solution to both of these problems is for the updating entities A solution to both of these problems is for the updating entities
(both DHCP clients and DHCP servers) to be able to detect that (both DHCP clients and DHCP servers) to be able to detect that
another entity has been associated with a DNS name, and to offer another entity has been associated with a DNS name, and to offer
administrators the opportunity to configure update behavior. administrators the opportunity to configure update behavior.
Specifically, a DHCID RR, described in DHCID RR[12] is used to Specifically, a DHCID RR, described in DHCID RR[11] is used to
associate client identification information with a DNS name and the associate client identification information with a DNS name and the
A RR associated with that name. When either a client or server adds A RR associated with that name. When either a client or server adds
an A RR for a client, it also adds a DHCID RR which specifies a an A RR for a client, it also adds a DHCID RR which specifies a
unique client identity (based on a "client specifier" created from unique client identity (based on a "client specifier" created from
the client's client-id or MAC address). In this model, only one A the client's client-id or MAC address). In this model, only one A
RR is associated with a given DNS name at a time. RR is associated with a given DNS name at a time.
By associating this ownership information with each A RR, By associating this ownership information with each A RR,
cooperating DNS updating entities may determine whether their client cooperating DNS updating entities may determine whether their client
is the first or last updater of the name (and implement the is the first or last updater of the name (and implement the
appropriately configured administrative policy), and DHCP clients appropriately configured administrative policy), and DHCP clients
which currently have a host name may move from one DHCP server to which currently have domain names may move from one DHCP server to
another without losing their DNS name. another without losing their DNS names.
The specific algorithms utilizing the DHCID RR to signal client The specific algorithms utilizing the DHCID RR to signal client
ownership are explained below. The algorithms only work in the case ownership are explained below. The algorithms only work in the case
where the updating entities all cooperate -- this approach is where the updating entities all cooperate -- this approach is
advisory only and is not substitute for DNS security, nor is it advisory only and is not substitute for DNS security, nor is it
replaced by DNS security. replaced by DNS security.
3.3.1 Format of the DHCID RRDATA 3.3.1 Format of the DHCID RRDATA
The DHCID RR used to hold the DHCP client's identity is formatted as The DHCID RR used to hold the DHCP client's identity is formatted as
skipping to change at page 6, line 12 skipping to change at page 6, line 26
Implementors should note that the actual identifying data is Implementors should note that the actual identifying data is
never placed into the DNS directly. Instead, the client-identity never placed into the DNS directly. Instead, the client-identity
data is used as the input into a one-way hash algorithm, and the data is used as the input into a one-way hash algorithm, and the
output of that hash is then used as DNS RRDATA. This has been output of that hash is then used as DNS RRDATA. This has been
specified in order to avoid placing data about DHCP clients that specified in order to avoid placing data about DHCP clients that
some sites might consider sensitive into the DNS. some sites might consider sensitive into the DNS.
When the updater is using the client's link-layer address, the first When the updater is using the client's link-layer address, the first
two bytes of the DHCID RRDATA MUST be zero. To generate the rest of two bytes of the DHCID RRDATA MUST be zero. To generate the rest of
the resource record, the updater MUST compute a one-way hash using the resource record, the updater MUST compute a one-way hash using
the MD5[13] algorithm across a buffer containing the client's the MD5[12] algorithm across a buffer containing the client's
network hardware type and link-layer address. Specifically, the network hardware type and link-layer address. Specifically, the
first byte of the buffer contains the network hardware type as it first byte of the buffer contains the network hardware type as it
appears in the DHCP htype field of the client's DHCPREQUEST message. appears in the DHCP htype field of the client's DHCPREQUEST message.
All of the significant bytes of the chaddr field in the client's All of the significant bytes of the chaddr field in the client's
DHCPREQUEST message follow, in the same order in which the bytes DHCPREQUEST message follow, in the same order in which the bytes
appear in the DHCPREQUEST message. The number of significant bytes appear in the DHCPREQUEST message. The number of significant bytes
in the chaddr field is specified in the hlen field of the in the chaddr field is specified in the hlen field of the
DHCPREQUEST message. DHCPREQUEST message.
When the updater is using a DHCP option sent by the client in its When the updater is using a DHCP option sent by the client in its
skipping to change at page 9, line 36 skipping to change at page 9, line 52
A and PTR RRs. Updating other types of RRs is outside the scope of A and PTR RRs. Updating other types of RRs is outside the scope of
this document. this document.
5. Security Considerations 5. Security Considerations
Unauthenticated updates to the DNS can lead to tremendous confusion, Unauthenticated updates to the DNS can lead to tremendous confusion,
through malicious attack or through inadvertent misconfiguration. through malicious attack or through inadvertent misconfiguration.
Administrators should be wary of permitting unsecured DNS updates to Administrators should be wary of permitting unsecured DNS updates to
zones which are exposed to the global Internet. Both DHCP clients zones which are exposed to the global Internet. Both DHCP clients
and servers SHOULD use some form of update request origin and servers SHOULD use some form of update request origin
authentication procedure (e.g., Simple Secure DNS Update[11]) when authentication procedure (e.g., Secure DNS Dynamic Update[10]) when
performing DNS updates. performing DNS updates.
Whether a DHCP client may be responsible for updating an FQDN to IP Whether a DHCP client may be responsible for updating an FQDN to IP
address mapping, or whether this is the responsibility of the DHCP address mapping, or whether this is the responsibility of the DHCP
server is a site-local matter. The choice between the two server is a site-local matter. The choice between the two
alternatives may be based on the security model that is used with alternatives may be based on the security model that is used with
the Dynamic DNS Update protocol (e.g., only a client may have the Dynamic DNS Update protocol (e.g., only a client may have
sufficient credentials to perform updates to the FQDN to IP address sufficient credentials to perform updates to the FQDN to IP address
mapping for its FQDN). mapping for its FQDN).
skipping to change at page 10, line 13 skipping to change at page 10, line 28
updates. In cases where a DHCP server is performing DNS updates on updates. In cases where a DHCP server is performing DNS updates on
behalf of a client, the DHCP server should be sure of the DNS name behalf of a client, the DHCP server should be sure of the DNS name
to use for the client, and of the identity of the client. to use for the client, and of the identity of the client.
Currently, it is difficult for DHCP servers to develop much Currently, it is difficult for DHCP servers to develop much
confidence in the identities of its clients, given the absence of confidence in the identities of its clients, given the absence of
entity authentication from the DHCP protocol itself. There are many entity authentication from the DHCP protocol itself. There are many
ways for a DHCP server to develop a DNS name to use for a client, ways for a DHCP server to develop a DNS name to use for a client,
but only in certain relatively unusual circumstances will the DHCP but only in certain relatively unusual circumstances will the DHCP
server know for certain the identity of the client. If DHCP server know for certain the identity of the client. If DHCP
Authentication[10] becomes widely deployed this may become more Authentication[9] becomes widely deployed this may become more
customary. customary.
One example of a situation which offers some extra assurances is one One example of a situation which offers some extra assurances is one
where the DHCP client is connected to a network through an MCNS where the DHCP client is connected to a network through an MCNS
cable modem, and the CMTS (head-end) of the cable modem ensures that cable modem, and the CMTS (head-end) of the cable modem ensures that
MAC address spoofing simply does not occur. Another example of a MAC address spoofing simply does not occur. Another example of a
configuration that might be trusted is one where clients obtain configuration that might be trusted is one where clients obtain
network access via a network access server using PPP. The NAS itself network access via a network access server using PPP. The NAS itself
might be obtaining IP addresses via DHCP, encoding a client might be obtaining IP addresses via DHCP, encoding a client
identification into the DHCP client-id option. In this case, the identification into the DHCP client-id option. In this case, the
skipping to change at page 11, line 11 skipping to change at page 11, line 23
[4] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and [4] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and
Answers to Commonly asked ``New Internet User'' Questions", Answers to Commonly asked ``New Internet User'' Questions",
RFC 1594, March 1994. RFC 1594, March 1994.
[5] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [5] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System", RFC 2136, April 1997. Updates in the Domain Name System", RFC 2136, April 1997.
[6] Bradner, S., "Key words for use in RFCs to Indicate [6] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[7] Eastlake, D., "Domain Name System Security Extensions", RFC [7] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
2535, March 1999.
[8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG) "Secret Key Transaction Authentication for DNS (TSIG)", RFC
(draft-ietf-dnsext-tsig-*)", July 1999. 2845, May 2000.
[10] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages [9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages
(draft-ietf-dhc-authentication-*)", June 1999. (draft-ietf-dhc-authentication-*)", June 1999.
[11] Wellington, B., "Simple Secure DNS Dynamic Updates [10] Wellington, B., "Secure DNS Dynamic Update", RFC 3007,
(draft-ietf-dnsext-simple-secure-update-*)", June 1999. November 2000.
[12] Stapp, M., Gustafsson, A. and T. Lemon, "A DNS RR for Encoding [11] Stapp, M., Gustafsson, A. and T. Lemon, "A DNS RR for Encoding
DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", July 2000. DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", November
2000.
[13] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, [12] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992. April 1992.
[14] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option [13] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option
(draft-ietf-dhc-fqdn-option-*.txt)", July 2000. (draft-ietf-dhc-fqdn-option-*.txt)", July 2000.
Author's Address Author's Address
Mark Stapp Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Dr. 250 Apollo Dr.
Chelmsford, MA 01824 Chelmsford, MA 01824
US USA
Phone: 978.244.8498 Phone: 978.244.8498
EMail: mjs@cisco.com EMail: mjs@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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