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

From: Ralph Droms <[email-masked]>
Date: Wed, 01 Jun 2005 15:26:49 -0400

(Cross-posted to namedroppers; see http://www1.ietf.org/mail-
archive/web/dhcwg/current/msg05005.html for earlier discussion of this
document)

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

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: Stuart Cheshire <[email-masked]>
Date: Thu, 16 Jun 2005 20:28:13 +0100

>Conflicts among DHCP Clients" <draft-ietf-dhc-ddns-resolution-08.txt>.

I just took a look at this, and it appears to have a trivial race 
condition:

6.3.1  Initial DHCID RR Query

   When a DHCP client or server intends to update an A or AAAA RR, it
   performs a DNS query with QNAME of the target name and with QTYPE of
   DHCID.

   If the query returns NXDOMAIN, the updater can conclude that the name
   is not in use and proceeds to Section 6.3.2.

What if two clients do this at the same time?

Surely this non-existence of the DHCID record needs to be expressed as a 
required precondition in the DNS UPDATE, so that it's performed 
conceptually as an atomic test-and-set operation?

In fact, that's exactly what Section 6.3.2 says, making Section 6.3.1 
completely redundant. Since the protocol has to work even when the 
Section 6.3.1 test yields the wrong result, Section 6.3.1 serves no 
purpose and should just be deleted.

Also, while I like the idea of DNS UPDATE clients being able effectively 
to tag their records to help identify later who was responsible for 
creating the record, I think the proposed DHCID solution is too 
DHCP-centric. IPv6 clients using stateless address autoconfiguration want 
to use DNS UPDATE too, and in order to be good citizens, they want to be 
able to tell whether the records they're about to stomp all over belong 
to them or to a different DNS UPDATE client. We need a tagging solution 
that works for both v4 and v6, without pre-supposing DHCP.

This is more than a passing academic interest. Starting in Mac OS X 10.4 
Tiger, Apple now ships a Secure DNS UPDATE client:

   <http://www.dns-sd.org/ClientSetup.html>

We face exactly the problems raised in this draft. Some sites configure 
per-user keys, in which case there's no problem because conflicts are 
simply not possible, because a user cannot update another's name. 
However, for the sake of similicity many sites configure a single site 
key for DNS update, trusting the users to cooperate with each other. 
Trusting users to cooperate is fine when the users are trustworthy and 
willing to cooperate, but even willing trustworthy users can't cooperate 
when the mechanisms for cooperation don't exist. Most people are willing 
to avoid stomping over someone else's name, but you can't expect them to 
do that if they have no reasonable way to know that the name is someone 
else's.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org