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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 28 Jun 2005 14:35:17 -0400

Ralph:

An updated draft has been submitted for publication and is available at
ftp://ftp-eng.cisco.com/volz/draft-ietf-dhc-ddns-resolution-09.txt.
While I hope this is it, I do recognize that some of the changes may
require another round. However, I'd really appreciate it if we can get
this completed before the IETF submission deadline!!

I've hopefully documented the significant changes to the draft below,
but I've also cleaned up a bunch of text (primarily as a result of
reading it while addressing Ralph's recommendations).

See below, prefixed by BV>. Please note that in some cases the text
below is close, but not exactly, what ended up in the draft because I
wrote this email as I went along and then did two additional passed
through the document.

Again, thanks for your thorough review Ralph!

I've also addressed Stuart's comment (see
http://www.ietf.org/mail-archive/web/dhcwg/current/msg05129.html) about
starting with section 6.3.2 instead of 6.3.1.

In section 6.3, I've added the following text:

   When a DHCP client or server intends to update A and/or AAAA RRs,
   it has two choices as to where to start the update sequence. The
   choice of whether to start with the lookup query in section 6.3.1
   or to start directly with the update in section 6.3.2 is left to
   the implementer.

   Implementers MAY use other algorithms, provided that the algorithm
   assures that the DNS updates are done with the proper prerequisites
   to prevent incorrect or incomplete updates should multiple updaters
be
   updating the same FQDN at once.

   As the update sequence below can result in loops, implementers SHOULD
   limit the total number of attempts for a single transaction.

I don't really want to add more than that, such as Ted's rationale (see
http://www.ietf.org/mail-archive/web/dhcwg/current/msg05131.html), for
why one might be better than the other.

I also added a few more cases to the algorithm to be more complete (so
6.3.1 and 6.3.3 have had more than just minor edits).

- 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

BV> I will add these definitions. MCNS is being replaced by DOCSIS (as
Suggested by Rich Woundy).

> 
> 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.

BV>Abstract is being replaced with the version previously exchanged via
email later the day of this original email.

> 
> 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.

BV>Hopefully adding ", as both the name and credentials must match", as
below, will help? (This also includes the editorial comment below):

   Sites that deploy Secure DNS [10 may configure credentials for
   each host and its assigned name in a way that is more
error-resistant,
   as both the name and credentials must match.

This was in the draft when I started working on it. I understand the
point, but not sure if it is clearly made.

> 
> 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.

BV> I revised the text in 6.2 (added " such that this DUID is used for
the DHCID RR by DHCPv4 and DHCPv6"). Hopefully that makes it clearer? I
don't think a discussion is warranted?

   Sites that wish to permit a single name to contain both A and AAAA
   RRs MUST make use of DHCPv4 clients and servers that support using
   the DHCP Unique Identifier (DUID) for DHCPv4 client identifiers such
   that this DUID is used for the DHCID RR by DHCPv4 and DHCPv6, see
[6].
   Otherwise, a dual-stack client that uses older-style DHCPv4 client
   identifiers [7] and [8]) will only be able to have either its A or
   AAAA record in DNS under a name because of the DHCID RR conflicts
   that result.

> 
> 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.

BV> Yes, there is no reason they can't be but practically speaking how
likely is this? DHCPv4 and DHCPv6 are separate protocols and it isn't
clear how likely combining the updates will be? However, I changed some
of the text to say and/or instead of just or (ie, A and/or AAAA RRs).

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

BV> I've added the following to that section:

   Techniques that may be considered to disambiguate names include
adding
   some type of suffix or prefix to the name or randomly generating a
   name.

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

BV> There shouldn't be. However, if you have two servers leasing out the
same addresses without some coordination (such as failover), you have
bigger problems than what's in the PTR record in DNS. Do you think we
need to explain this???

> 
> -----
> Editorial comments:
> 
> The term "lease" is often used where the terms "IP address" or
> "assigned IP address" would be more precise.

BV> Done. I've generally used "assigned IP address".

> 
> "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.

BV> Done.
 
> 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.+}

BV> Done. But again, I think the updates of both in one requests will
not be common if the DHCP server is doing the updates because we have
two, not one, DHCP protocol.

> 
>  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.

BV> Done. But most of the name conflicts are among clients, not servers.
Though I guess if servers generate random names, they could still
conflict.

> 
> 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?

BV> Done.

> 
> 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.

BV> Done.

> 
> 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.+}

BV> Done. See above.

> 
> 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.

BV> Done, except I changed "whether or not" to just "if" because
"whether or not it is not" is, IMHO, really bad wording. "if it is not"
sounds much better.

> 
> 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.

BV> I used:

   It is possible to arrange for DHCP servers to perform A and/or AAAA
   RR updates on behalf of their clients. If a single DHCP server
manages
   all of the DHCP clients at a site, it can maintain a database of the
   FQDNs in use, and can check that database before initiating a FQDN
for
   a client. Such a database is necessarily proprietary, however, and
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.

BV> Done.

> 
> 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.

BV> I changed rarely to infrequently. While this may not be true in the
future with true peer-to-peer, this section refers to the TTL
calculation and so I think it is OK?

I also added that bounds on the TTL value should be configurable. A
lower bound was already implicit (10 minutes).

I also added:

   While clients and servers MAY update the TTL of the records as the
   lease or lifetime is about to expire, there is no requirement that
they
   do so as this puts additional load on the DNS system with likely
little
   benefit.

> 
> 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?

BV> I think that is way to complex and too much overhead to be worth it?

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

BV> I changed it to "IPv6 clients require updates of AAAA RRs; IPv4
client require updates of 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.

BV> This is an important condition. NOERROR also is returned in the next
paragraph since that returns an answre to the QUERY! So that this is
clear, I changed the next paragraph from:

   If the DHCID rrset is returned,

To:

   If the query returns NOERROR with a DHCID rrset,

> 
> 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.

BV> Ok, I changed MUST NOT to SHOULD NOT.

> 
> 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.

BV> You'll have to ask the original authors. I took it to mean that if
anyone can do updates, they might change anything out from under you and
that could cause bad data in DNS.

I've dropped this sentence from the section.

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

BV> Ralph, I'm lost as to what your issue is here. This is the SECURITY
CONSIDERATIONS section so why shouldn't it talk about authentication of
DNS updates? It says use AUTHENTICATED updates? What's wrong with that?
Isn't that security?

> 
> -----
> 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].

BV> Done.

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

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