Subject: [dhcwg] dhc WG last call on <draft-ietf-dhc-ddns-resolution-08.txt>

From: Ralph Droms <[email-masked]>
Date: Wed, 25 May 2005 18:46:56 -0400

This message announces a WG last call on "Resolution of DNS Name
Conflicts among DHCP Clients" <draft-ietf-dhc-ddns-resolution-08.txt>.
The last call will conclude at 1700 EST (USA) on 2005-04-25.

Please respond to this WG last call.  Note that this is the *second*
last call for this document.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

If you commented about this document between the first last call and
this new last call, please repost your comment so we can be sure to
assess all support for the document.

Summary:

There are options in DHCP that can be used for transmitting
information about updating DNS. However, these do not explicitly
control updating the name to address and address to name mappings
maintained in the DNS, as performed by hosts acting as DHCP clients
and servers. draft-ietf-dhc-ddns-resolution-08.txt describes
techniques for the resolution of DNS name conflicts among DHCP clients
and servers.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-
resolution-08.txt

- Ralph Droms 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Thu, 26 May 2005 12:01:40 -0400

In general, I think the mechanism specified in this document is fully
baked and useful.

I do have some substantive comments and many editorial comments:

Substantive comments:

The Terminology section should have a list of acronyms and terms used
in the doc; e.g., FQDN, Name Conflict, MCNS

The Abstract is not clear and does not accurately reflect the intent
and the contents of the doc.  I suggest:

   Abstract

   DHCP provides a mechanism for host configuration that includes
   dynamic assignment of IP addresses.  To maintain accurate IP
   address and IP address to name mappings in the DNS, these
   dynamically assigned addresses require updates to the DNS.
   Conflicts may arise between updates to the DNS from different
   sources. This document describes techniques for the resolution of
   DNS name conflicts arising from updates to the DNS to reflect
   dynamic IP address assignment.

I read the last sentence of the first paragraph of 3.1 to imply that
Secure DNS can mitigate the problem of name conflicts.  Can Secure DNS
mitigate or preclude name conflicts; I'm not sure it has any effect on
name conflicts:

   Sites that
   deploy Secure DNS [10] may configure credentials for each host and
   its assigned name in a way that is more -error-resistant, but this
   level of pre-configuration is still rare in DHCP environments.

I knew to look for it, but found that the explanation in
draft-ietf-dnsext-dhcid-rr of how to use the new style of IPv4 client
identifier defined in draft-ietf-dhc-3315id-for-v4 is obscure.  I
think it would be good, perhaps in a DISCUSSION, to point out that the
use of 3315id-for-v4 identifiers leads to exactly the same data in the
DHCID RR, because the DUID portion is encoded as an IPv6-style
identifier.

In the update mechanisms in section 6.3.2, is it possible for both the
A and AAA RRs to be updated simultaneously?  The text seems to refer
to "A or AAAA" throughout section 6.

What does "perform some name disambiguation operation on behalf of the
current client" in the first paragraph of section 6.3.4 mean?

Is there any possibility of a name conflict related to PTR records
(section 6.4)?

-----
Editorial comments:

The term "lease" is often used where the terms "IP address" or
"assigned IP address" would be more precise.

"DNS name", "domain name" and "FQDN" are used interchangeably
throughout the doc.  For consistency, choose one term - I would
recommend FQDN - and use it throughout.

A and AAAA RRs are not mutually exclusive.  The text should be edited
to reflect that a client may have both A and AAAA RRs simultaneously.
For example, in the first paragraph of section 2, change the third
sentence:

   Through the use of the client FQDN option, DHCP clients and servers
   can negotiate the client's FQDN and the allocation of
   responsibility for updating the DHCP client's A [-or-] {+and+} AAAA
   [-RR.-] {+RRs.+}

 Both clients and servers can experience name conflicts.  Change the
 last sentence of the first paragraph of section 2:

   This document identifies situations in which conflicts in the use
   of FQDNs may arise among DHCP [-clients,-] {+clients and servers,+}
   and describes a strategy for the use of the DHCID DNS resource
   record [2] in resolving those conflicts.

The term "Name Conflict" is defined in the first paragraph of section
3 but not used anywhere else in the document (except in the title).
Drop the definition?

Change the first two sentences of section 3.1:

   [-At many (though not all) sites, administrators-] {+Administrators
   may+} wish to maintain a one-to-one relationship between active
   DHCP clients and domain names, and to maintain consistency between
   a host's [-A-] {+A, AAAA+} and PTR RRs.  Hosts that are not
   represented in the DNS, or hosts [-which-] {+that+} inadvertently
   share an FQDN with another host may encounter inconsistent behavior
   or may not be able to obtain access to network resources.

Change the last sentence of the first paragraph of section 3.1:

   Sites that deploy Secure DNS [10] may configure credentials for
   each host and its assigned name in a way that is more
   [-error-resistant, but this level of pre-configuration is still
   rare in DHCP environments.-] {+error-resistant.+}

Change the last paragraph on page 4 (includes examples of replacing
"lease" with the more precise "IP address" or "assigned IP address"):

   If the policy is that the first DHCP client with a given name
   should be the only client associated with that name, Client B needs
   to be able to determine [-that-] {+whether or not+} it is not the
   client associated with "foo.org.nil".  It could be that Client A
   booted first, and that Client B should choose another name.  Or it
   could be that B has booted on a new subnet, and received a new
   [-lease.-] {+IP address, in which case B should update the DNS with
   its new IP address.+} It must either retain persistent state about
   the last [-lease-] {+IP address+} it [-held-] {+was assigned+} (in
   addition to its current [-lease)-] {+IP address)+} or it must have
   some other way to detect that it was the last updater of
   "foo.org.nil" in order to implement the site's policy.

In the first sentence of section 3.2, "At many sites" is
unsubstantiated and unnecessary.  Change the paragraph to:

   [-At many sites, the difficulties with distributing DNS update
   credentials to all of the DHCP clients lead-] {+It is possible+} to
   [-the desire-] {+arrange+} for [-the-] DHCP servers to perform A RR
   updates on behalf of their clients.  If a single DHCP server
   [-managed-] {+manages+} all of the DHCP clients at a site, it
   [-could-] {+can+} maintain [-some-] {+a+} database of the DNS names
   [-that-] it [-was managing,-] {+manages,+} and {+can+} check that
   database before initiating a DNS update for a client.  Such a
   database is necessarily proprietary, however, and [-that-] {+the+}
   approach does not work once more than one DHCP server is deployed.

Change the second paragraph of section 3.2 to:

   {+When multiple DHCP servers are deployed, the servers require a
   way to coordinate the identities of DHCP clients.+} Consider an
   example in which DHCP Client A boots, obtains [-a DHCP lease-] {+an
   IP address+} from Server S1, presenting the hostname "foo" in a
   Client FQDN option [4] in its DHCPREQUEST message.  Server S1
   updates [-its domain name,-] {+the FQDN+} "foo.org.nil", adding an
   A RR [-that matches Client A's lease.-] {+containing the IP address
   assigned to A.+} 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 [-lease,-] {+IP address,+} and will attempt to add
   an A RR [-matching-] {+containing+} the [-new lease-] {+newly
   assigned IP address+} to {+the FQDN+} "foo.org.nil".  At this
   point, without some communication mechanism 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 is currently
   associated with the domain name, or whether A is a different client
   configured with the same hostname.  If the servers cannot
   distinguish between these situations, they cannot enforce the
   site's naming policies.

The second paragraph of section 5 includes text about whether FQDNs
for DHCP clients are ever resolved through DNS.  The text argues
against the need for any DNS updates for DHCP clients (!).  Will the
assertions in this text be true in the future, especially if more
point-to-point applications are deployed?

   In deployment, this rarely if ever represents a
   significant problem.  Most DHCP-managed hosts are rarely looked-up by
   name in the DNS, and the deployment of IXFR (RFC 1995 [14]) and
   NOTIFY (RFC 1996 [15]) can reduce the latency between updates and
   their visibility at secondary servers.

In the third paragraph of section 5, from what principles of DNS or
operational experience is this recommendation derived: "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."?  What about dynamic update
of the TTL to match lease expiration time?

What does this sentence in section 6.2 mean: "IPv6 clients will be
represented by AAAA RRs; IPv4 clients by A RRs."?

In the third paragraph in section 6.3.1, does the second sentence
describe the only situation in whith NOERROR can be returned or is it
just an example?  Can the second sentence simply be dropped?

   If the query returns NOERROR but without an answer, 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.

In the fifth paragraph of section 6.3.1, is it truly a MUST NOT or is
it up to local policy:

   If any other status is returned, the updater MUST NOT attempt an
   update.

What is "confusion" in the first sentence of section 7?

   Unauthenticated updates to the DNS can lead to tremendous
   confusion, through malicious attack or through inadvertent
   misconfiguration.

Why does section 7 talk about authentication of DNS updates, while
this document describes a procedure for avoiding name conflicts?

-----
Typos:

Change the last sentence section 2:

   Furthermore, this specification applies only to DHCP client and
   server [-processes:-] {+processes;+} it does not apply to other
   processes that initiate DNS updates.

Add commas around "if ever" in the second paragraph of section 5.

In the fourth paragraph of section 6.3.1, I think the citation of [4]
should be replaced by [2].

---

From: Ralph Droms <[email-masked]>
Date: Thu, 26 May 2005 12:17:56 -0400

(Correction to suggested abstract)

   Abstract

   dynamic assignment of IP addresses.  To maintain accurate name to IP