draft-ietf-dhc-ddns-resolution-05.txt   draft-ietf-dhc-ddns-resolution-06.txt 
DHC Working Group M. Stapp DHC Working Group M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: May 2, 2003 November 1, 2002 Expires: April 26, 2004 October 27, 2003
Resolution of DNS Name Conflicts Among DHCP Clients Resolution of DNS Name Conflicts Among DHCP Clients
<draft-ietf-dhc-ddns-resolution-05.txt> <draft-ietf-dhc-ddns-resolution-06.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 May 2, 2003. This Internet-Draft will expire on April 26, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). 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, and specifically updating the name to address
updating the name to address and address to name mappings maintained and address to name mappings maintained in the DNS. This document
in the DNS. describes techniques for the resolution of DNS name conflicts among
DHCP clients.
The "Client FQDN Option"[3] specifies the client FQDN option,
through which DHCP clients and servers can exchange information
about client FQDNs. This document describes techniques for the
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 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 . . . . . . . . . . . . . . . . . . . . 5 3.2 Multiple DHCP Servers . . . . . . . . . . . . . . . . . . . 5
4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 5 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 5
5. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Procedures for performing DNS updates . . . . . . . . . . . . 6 6. Procedures for performing DNS updates . . . . . . . . . . . 6
6.1 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . . 6 6.1 Error Return Codes . . . . . . . . . . . . . . . . . . . . . 6
6.2 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . . 7 6.2 Dual IPv4/IPv6 Client Considerations . . . . . . . . . . . . 6
6.3 Removing Entries from DNS . . . . . . . . . . . . . . . . . . 7 6.3 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . 7
6.4 Updating Other RRs . . . . . . . . . . . . . . . . . . . . . . 8 6.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6.3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.4 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 6.5 Removing Entries from DNS . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 6.6 Updating Other RRs . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . 12
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[4]. document are to be interpreted as described in RFC 2119[1].
2. Introduction 2. Introduction
"The Client FQDN Option"[3] includes a description of the operation "The Client FQDN Option"[6] includes a description of the operation
of DHCP[5] clients and servers that use the client FQDN option. of DHCP[7] 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. This document identifies for updating the DHCP client's A or AAAA RR. This document
situations in which conflicts in the use of FQDNs may arise among identifies situations in which conflicts in the use of FQDNs may
DHCP clients, and describes a strategy for the use of the DHCID DNS arise among DHCP clients, and describes a strategy for the use of
resource record[6] in resolving those conflicts. the DHCID DNS resource record[4] in resolving those conflicts.
In any case, whether a site permits all, some, or no DHCP servers In any case, whether a site permits all, some, or no DHCP servers
and clients to perform DNS updates into the zones that it controls and clients to perform DNS updates (RFC 2136[5], RFC 3007[11]) into
is entirely a matter of local administrative policy. This document the zones that it controls is entirely a matter of local
does not require any specific administrative policy, and does not administrative policy. This document does not require any specific
propose one. The range of possible policies is very broad, from administrative policy, and does not propose one. The range of
sites where only the DHCP servers have been given credentials that possible policies is very broad, from sites where only the DHCP
the DNS servers will accept, to sites where each individual DHCP servers have been given credentials that the DNS servers will
client has been configured with credentials that allow the client to accept, to sites where each individual DHCP client has been
modify its own domain name. Compliant implementations MAY support configured with credentials that allow the client to modify its own
some or all of these possibilities. Furthermore, this specification domain name. Compliant implementations MAY support some or all of
applies only to DHCP client and server processes: it does not apply these possibilities. Furthermore, this specification applies only to
to other processes that initiate DNS updates. DHCP client and server processes: it does not apply to other
processes that initiate DNS updates.
3. Issues with DNS Update in DHCP Environments 3. Issues with DNS Update 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 4, line 17 skipping to change at page 4, line 17
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 a host's A and PTR RRs. names, and to maintain consistency between a host's A and PTR RRs.
Hosts that are not represented in the DNS, or hosts which Hosts that 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 that deploy Secure DNS[9] may configure credentials for each Sites that deploy Secure DNS[10] 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.
Consider an example in which two DHCP clients in the "org.nil" Consider an example in which two DHCP clients in the "org.nil"
network are both configured with the name "foo". The clients are network are both configured with the name "foo". The clients are
permitted to perform their own DNS updates. The first client, client permitted to perform their own DNS updates. The first client, client
A, is configured via DHCP. It adds an A RR to "foo.org.nil", and its A, is configured via DHCP. It adds an A RR to "foo.org.nil", and its
DHCP server adds a PTR RR corresponding to its IP address lease. DHCP server adds a PTR RR corresponding to its IP address lease.
When the second client, client B, boots, it is also configured via When the second client, client B, boots, it is also configured via
skipping to change at page 5, line 18 skipping to change at page 5, line 18
credentials to all of the DHCP clients lead to the desire for the credentials to all of the DHCP clients lead to the desire for the
DHCP servers to perform A RR updates on behalf of their clients. If DHCP servers to perform A RR updates on behalf of their clients. If
a single DHCP server managed all of the DHCP clients at a site, it a single DHCP server managed all of the DHCP clients at a site, it
could maintain some database of the DNS names that it was managing, could maintain some database of the DNS names that it was managing,
and check that database before initiating a DNS update for a client. and check that database before initiating a DNS update for a client.
Such a database is necessarily proprietary, however, and that Such a database is necessarily proprietary, however, and that
approach does not work once more than one DHCP server is deployed. approach does not work once more than one DHCP server is deployed.
Consider an example in which DHCP Client A boots, obtains a DHCP Consider an example in which DHCP Client A boots, obtains a DHCP
lease from Server S1, presenting the hostname "foo" in a Client FQDN lease from Server S1, presenting the hostname "foo" in a Client FQDN
option[3] in its DHCPREQUEST message. Server S1 updates its domain option[6] in its DHCPREQUEST message. Server S1 updates its domain
name, "foo.org.nil", adding an A RR that matches Client A's lease. name, "foo.org.nil", adding an A RR that matches Client A's lease.
The client then moves to another subnet, served by Server S2. When The client then moves to another subnet, served by Server S2. When
Client A boots on the new subnet, Server S2 will issue it a new Client A boots on the new subnet, Server S2 will issue it a new
lease, and will attempt to add an A RR matching the new lease to lease, and will attempt to add an A RR matching the new lease to
"foo.org.nil". At this point, without some communication mechanism "foo.org.nil". At this point, without some communication mechanism
which S2 can use to ask S1 (and every other DHCP server that updates which S2 can use to ask S1 (and every other DHCP server that updates
the zone) about the client, S2 has no way to know whether Client A the zone) about the client, S2 has no way to know whether Client A
is currently associated with the domain name, or whether A is a is currently associated with the domain name, or whether A is a
different client configured with the same hostname. If the servers different client configured with the same hostname. If the servers
cannot distinguish between these situations, they cannot enforce the cannot distinguish between these situations, they cannot enforce the
site's naming policies. 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, specified in [6], is used to associate For this purpose, a DHCID RR, specified in [4], 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 that specifies a A or PTR RR for a client, it also adds a DHCID RR that specifies a
unique client identity, based on data from the client's DHCPREQUEST unique client identity, based on data from the client's DHCPREQUEST
message. In this model, only one A RR is associated with a given DNS message. In this model, only one A RR is associated with a given DNS
name at a time. 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 6, line 15 skipping to change at page 6, line 15
where the updating entities all cooperate -- this approach is where the updating entities all cooperate -- this approach is
advisory only and is not a substitute for DNS security, nor is it advisory only and is not a substitute for DNS security, nor is it
replaced by DNS security. replaced by DNS security.
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 that perform statically configured RRs. DHCP clients and servers that 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. answers to DNS queries will return records that refer to DHCP lease
bindings that have expired.
A reasonable basis for RR TTLs is the lease duration itself. The RR The coupling among primary, secondary, and caching DNS servers is
TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed 'loose'; that is a fundamental part of the design of the DNS. This
1/3 of the lease time, and SHOULD be at least 10 minutes. We looseness makes it impossible to prevent all possible situations in
recognize that individual administrators will have varying which a resolver may return a record reflecting a DHCP lease binding
requirements: DHCP servers and clients SHOULD allow administrators that has expired. In deployment, this rarely if ever represents a
to configure TTLs, either as an absolute time interval or as a significant problem. Most DHCP-managed hosts are rarely looked-up by
percentage of the lease time. In general, the TTLs or RRs added as a name in the DNS, and the deployment of IXFR (RFC 1995[14]) and
result of DHCP lease activity SHOULD be less than the initial lease NOTIFY (RFC 1996[15]) can reduce the latency between updates and
time. their visibility at secondary servers.
We suggest these basic guidelines for implementors. In general, the
TTLs for RRs added as a result of DHCP lease activity SHOULD be less
than the initial lease time. The RR TTL on a DNS record added for a
DHCP lease SHOULD NOT exceed 1/3 of the lease time, and SHOULD be at
least 10 minutes. We recognize that individual administrators will
have varying requirements: DHCP servers and clients SHOULD allow
administrators to configure TTLs, either as an absolute time
interval or as a percentage of the lease time.
6. Procedures for performing DNS updates 6. Procedures for performing DNS updates
6.1 Adding A RRs to DNS 6.1 Error Return Codes
When a DHCP client or server intends to update an A RR, it first Certain RCODEs defined in RFC 2136[5] indicate that the destination
prepares a DNS UPDATE query that includes as a prerequisite the DNS server cannot perform an update: FORMERR, SERVFAIL, REFUSED,
assertion that the name does not exist. The update section of the NOTIMP. If one of these RCODEs is returned, the updater MUST
query attempts to add the new name and its IP address mapping (an A terminate its update attempt. Because these errors may indicate a
RR), and the DHCID RR with its unique client-identity. misconfiguration of the updater or of the DNS server, the updater
MAY attempt to signal to its administrator that an error has
occurred, e.g. through a log message.
If this update operation succeeds, the updater can conclude that it 6.2 Dual IPv4/IPv6 Client Considerations
has added a new name whose only RRs are the A and DHCID RR records.
The A RR update is now complete (and a client updater is finished,
while a server might proceed to perform a PTR RR update).
If the first update operation fails with YXDOMAIN, the updater can At the time of publication of this document, a small minority of
conclude that the intended name is in use. The updater then DHCP clients support both IPv4 and IPv6. We anticipate, however,
attempts to confirm that the DNS name is not being used by some that a transition will take place over a period of time, and more
sites will have dual-stack clients present. IPv6 clients will be
represented by AAAA RRs; IPv4 clients by A RRs. The administrators
of some mixed deployments may wish to permit a single name to
contain A and AAAA RRs from different clients. Other deployments may
wish to restrict the use of a DNS name to a single DHCP client, and
allow only A and AAAA RRs reflecting that client's DHCP leases.
6.3 Adding A RRs to DNS
6.3.1
When a DHCP client or server intends to update an A RR, it performs
a DNS query with QNAME of the target name, and QTYPE is DHCID. If
the result is NXDOMAIN, the updater can conclude that the name is
not in use. In that case, the updater prepares a DNS UPDATE query
that includes as a prerequisite the assertion that the name does not
exist. The update section of the query attempts to add the new name
and its IP address mapping (an A RR), and the DHCID RR with its
unique client-identity.
If the query returns with NODATA, the updater can conclude that the
target name is in use, but that no DHCID RR is present. This
indicates that some records have been configured by an
administrator. Whether the updater proceeds with an update is a
matter of local administrative policy.
If the DHCID rrset is returned, the updater uses the hash
calculation defined in the DHCID RR specification[4] to determine
whether the client associated with the name matches the current
client's identity. If so, the updater proceeds following the steps
in [subsection xxx].
If any other status is returned, the updater MUST NOT attempt an
update.
6.3.2
If the update operation in Section 6.3.1 fails with YXDOMAIN, the
updater can conclude that the intended name is in use. The updater
then attempts to confirm that the DNS name is not being used by some
other host. The updater prepares a second UPDATE query in which the other host. The updater prepares a second UPDATE query in which the
prerequisite is that the desired name has attached to it a DHCID RR prerequisite is that the desired name has attached to it a DHCID RR
whose contents match the client identity. The update section of whose contents match the client identity. The update section of
this query deletes the existing A records on the name, and adds the this query deletes the existing A records on the name, and adds the
A record that matches the DHCP binding and the DHCID RR with the A record that matches the DHCP binding and the DHCID RR with the
client identity. client identity.
If this query succeeds, the updater can conclude that the current If this query succeeds, the updater can conclude that the current
client was the last client associated with the domain name, and that client was the last client associated with the domain name, and that
the name now contains the updated A RR. The A RR update is now the name now contains the updated A RR. The A RR update is now
complete (and a client updater is finished, while a server would complete (and a client updater is finished, while a server would
then proceed to perform a PTR RR update). then proceed to perform a PTR RR update).
6.3.3
If the second query fails with NXRRSET, the updater must conclude If the second query fails with NXRRSET, the updater must conclude
that the client's desired name is in use by another host. At this that the client's desired name is in use by another host. At this
juncture, the updater can decide (based on some administrative juncture, the updater can decide (based on some administrative
configuration outside of the scope of this document) whether to let configuration outside of the scope of this document) whether to let
the existing owner of the name keep that name, and to (possibly) the existing owner of the name keep that name, and to (possibly)
perform some name disambiguation operation on behalf of the current perform some name disambiguation operation on behalf of the current
client, or to replace the RRs on the name with RRs that represent client, or to replace the RRs on the name with RRs that represent
the current client. If the configured policy allows replacement of the current client. If the configured policy allows replacement of
existing records, the updater submits a query that deletes the existing records, the updater submits a query that deletes the
existing A RR and the existing DHCID RR, adding A and DHCID RRs that existing A RR and the existing DHCID RR, adding A and DHCID RRs that
skipping to change at page 7, line 30 skipping to change at page 8, line 32
DISCUSSION: DISCUSSION:
The updating entity may be configured to allow the existing DNS The updating entity may be configured to allow the existing DNS
records on the domain name to remain unchanged, and to perform records on the domain name to remain unchanged, and to perform
disambiguation on the name of the current client in order to disambiguation on the name of the current client in order to
attempt to generate a similar but unique name for the current attempt to generate a similar but unique name for the current
client. In this case, once another candidate name has been client. In this case, once another candidate name has been
generated, the updater should restart the process of adding an A generated, the updater should restart the process of adding an A
RR as specified in this section. RR as specified in this section.
6.2 Adding PTR RR Entries to DNS 6.4 Adding PTR RR Entries to DNS
The DHCP server submits a DNS query that deletes all of the PTR RRs The DHCP server submits a DNS query that deletes all of the PTR RRs
associated with the lease IP address, and adds a PTR RR whose data associated with the lease IP address, and adds a PTR RR whose data
is the client's (possibly disambiguated) host name. The server MAY is the client's (possibly disambiguated) host name. The server MAY
also add a DHCID RR as specified in Section 4. also add a DHCID RR as specified in Section 4.
6.3 Removing Entries from DNS 6.5 Removing Entries from DNS
The most important consideration in removing DNS entries is be sure The most important consideration in removing DNS entries is be sure
that an entity removing a DNS entry is only removing an entry that that an entity removing a DNS entry is only removing an entry that
it added, or for which an administrator has explicitly assigned it it added, or for which an administrator has explicitly assigned it
responsibility. responsibility.
When a lease expires or a DHCP client issues a DHCPRELEASE request, When a lease expires or a DHCP client issues a DHCPRELEASE request,
the DHCP server SHOULD delete the PTR RR that matches the DHCP the DHCP server SHOULD delete the PTR RR that matches the DHCP
binding, if one was successfully added. The server's update query binding, if one was successfully added. The server's update query
SHOULD assert that the name in the PTR record matches the name of SHOULD assert that the name in the PTR record matches the name of
skipping to change at page 8, line 23 skipping to change at page 9, line 26
If the query fails, the updater MUST NOT delete the DNS name. It If the query fails, the updater MUST NOT delete the DNS name. It
may be that the client whose lease on has expired has moved to may be that the client whose lease on has expired has moved to
another network and obtained a lease from a different server, which another network and obtained a lease from a different server, which
has caused the client's A RR to be replaced. It may also be that has caused the client's A RR to be replaced. It may also be that
some other client has been configured with a name that matches the some other client has been configured with a name that matches the
name of the DHCP client, and the policy was that the last client to name of the DHCP client, and the policy was that the last client to
specify the name would get the name. In these cases, the DHCID RR specify the name would get the name. In these cases, the DHCID RR
will no longer match the updater's notion of the client-identity of will no longer match the updater's notion of the client-identity of
the host pointed to by the DNS name. the host pointed to by the DNS name.
6.4 Updating Other RRs 6.6 Updating Other RRs
The procedures described in this document only cover updates to the The procedures described in this document only cover updates to the
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.
7. Security Considerations 7. 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
skipping to change at page 9, line 38 skipping to change at page 10, line 40
client-id. client-id.
8. Acknowledgements 8. Acknowledgements
Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter
Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, R. Barr Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, R. Barr
Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis,
Josh Littlefield, Michael Patton, Glenn Stump, and Bernie Volz for Josh Littlefield, Michael Patton, Glenn Stump, and Bernie Volz for
their review and comments. their review and comments.
References Normative References
[1] Mockapetris, P., "Domain names - Concepts and Facilities", RFC [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
1034, Nov 1987. 1034, Nov 1987.
[2] Mockapetris, P., "Domain names - Implementation and [3] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, Nov 1987. Specification", RFC 1035, Nov 1987.
[3] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option [4] Stapp, M., Gustafsson, A. and T. Lemon, "A DNS RR for Encoding
(draft-ietf-dhc-fqdn-option-*.txt)", March 2001. DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", October 2003.
[4] Bradner, S., "Key words for use in RFCs to Indicate [5] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Requirement Levels", RFC 2119, March 1997. Updates in the Domain Name System", RFC 2136, April 1997.
[5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Informative References
[6] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option
(draft-ietf-dhc-fqdn-option-*.txt)", October 2003.
[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[6] Stapp, M., Gustafsson, A. and T. Lemon, "A DNS RR for Encoding [8] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
DHCP Information (draft-ietf-dnsext-dhcid-rr-*)", March 2001. April 1992.
[7] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and [9] 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.
[8] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [10] Eastlake, D., "Domain Name System Security Extensions", RFC
Updates in the Domain Name System", RFC 2136, April 1997.
[9] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[10] Wellington, B., "Secure Domain Name System (DNS) Dynamic [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. Update", RFC 3007, November 2000.
[11] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992.
[12] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, [12] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC "Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000. 2845, May 2000.
[13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001. RFC 3118, June 2001.
[14] Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
[15] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
Author's Address Author's Address
Mark Stapp Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Dr. 1414 Massachusetts Ave.
Chelmsford, MA 01824 Boxborough, MA 01719
USA USA
Phone: 978.244.8498 Phone: 978.936.1535
EMail: mjs@cisco.com EMail: mjs@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). 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/