Subject: RE: Use of DHCID in draft-ietf-dhc-dhcp-dns-12

From: Mark Stapp <[email-masked]>
Date: Wed, 05 Jul 2000 12:54:11 -0400

Sorry I was out of the loop for the start of this exchange. Let me try to 
answer the specific questions you asked, and explain what I plan to do for 
the next ietf.

I've specified that a DHCID rr be associated with any A or PTR rr that's 
added by a dhcp client or server. There's no way for an updater to 
distinguish between RRs that have been added by an administrator and RRs 
that have been added via ddns updates without such an association. It's 
seemed to me that the presence of the DHCID rr makes it possible to do two 
things. First, updaters who discover PTR rrs without an appropriate DHCID 
rr could be configured to avoid updates (or at least log warnings about 
them) if they might interfere with some administrator's intentions. Second, 
administrative applications can use the presence of the DHCID rr to warn a 
user that an administrative change may affect rrs that dhcp servers think 
they are responsible for.

I had proposed using a form of the KEY rr to associate dhcp information 
with other rrs in earlier versions of the draft. The DNSEXT folks were 
adamant in reserving the use of KEY for security-related information 
exclusively, and a clever DNS person proposed the DHCID rr as a solution. I 
agree that it's unfortunate that there are deployment difficulties in 
adding a new rrtype, but that's sort of where we are.

As a result of some discussions that took place during the Adelaide ietf, 
I'm splitting the single dhcp-dns draft into three pieces. There will be an 
"FQDN Option" draft, a draft on the use of the DHCID rr to detect and 
resolve DDNS conflicts, and a draft with suggestions for using the DDNS 
prerequisites to accomplish that. I'll also be re-submitting the DHCID 
draft to the dnsext working group. At this point, I don't plan to make 
significant changes to the mechanism as it stands in dhcp-dns-12.

Regards,
Mark

At 09:01 AM 6/30/00 -0500, you wrote:

>Thanks for the reply. I do understand the concept of who owns each record.
>I just didn't see a purpose for the DHCID associated with the PTR, other
>than as you suggested, it being a mechanism for an administrator to try and
>tell who updated the record. Although, if it is "scrambled" via a hash
>algorithm, I'm still not sure how useful it would be.
>
>I guess I was just looking for a more definitive answer, like "oh that's
>there because in the next version of the draft you'll see...." or "Yes you
>are correct, and there really isn't a need for a DHCID record associated
>with a PTR record."
>
>Presently, since BIND8 DNS doesn't support DHCID (at least to my
>knowledge), does anyone see a problem with using the KEY RR in place of the
>DHCID which was the proposed method in a previous version of the subject
>draft? At least that way a DHCP server capable of dynamic DNS updates could
>be developed now that would interface to any BIND 8 DNS server.
>
>Jack Corcoran
>[email-masked]
>  Ph  607-752-5570,  T/L 852-5570, FAX: 607-752-5421
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 05 Jul 2000 15:33:26 -0400

Mark - is there any chance you will be able to rev the drafts by the 
publication deadline for the Pittsburgh IETF (7/14)?  Anything I can do to 
help?

- Ralph