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

From: Ralph Droms <[email-masked]>
Date: Sat, 09 Jul 2005 17:38:03 -0400

Stuart - in response to your comments during the previous last call on
draft-ietf-dhc-ddns-resolution-08.txt>, from my notes on the resolution
of issues raised during an earlier last call on this document:

Issue 1, Issue 2:

   The DHCID RR represents an advisory lock used by entities using
   DHCP to resolve conflicts in the use of DNS records.  Is it
   limiting to restrict the RR to use by DHCP participants, because
   there might be other scenarios in the future that could use the
   same advisory lock mechanism?  Or, should the DHCID RR be reserved
   for use in conjunction with DHCP?

   Resolution: The DHCID RR will be reserved for the exclusive use of
   DHCP participants:
   
   * The hash mechanism used to generate the data in the DHCID RR is
     DHCP-specific
   * There are no other mechanisms known of today that would use this
     mechanism; any future mechanisms that require a similar function
     can define a new RR for that purpose

   Changes to docs: none required

I don't have pointers to the earlier discussion immediately available...

- Ralph

On Thu, 2005-06-16 at 20:28 +0100, Stuart Cheshire wrote:
> >This message announces a WG last call on "Resolution of DNS Name
> >Conflicts among DHCP Clients" <draft-ietf-dhc-ddns-resolution-08.txt>.
>
> [...]
>
> 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
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

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