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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 27 May 2005 09:02:25 -0400

Thanks for the extensive feedback.

I haven't yet reviewed all of the comments in depth, but they seem very
appropriate.

I think I'll wait to see if any other comments appear over the WG Last
Call and then respin the draft with these revisions (and the new
abstract discussed separately).

- Bernie 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ralph Droms (rdroms)
> Sent: Thursday, May 26, 2005 12:02 PM
> To: [email-masked]
> Subject: Re: [dhcwg] dhc WG last call 
> on<draft-ietf-dhc-ddns-resolution-08.txt>
> 
> 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].
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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