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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 22 Jul 2005 14:58:16 -0400

David:

I'm inclined to leave the text as it is.

The draft doesn't address the issue of failures related to communicating
with the "wrong" nameserver, timeouts, etc. It is always possible that
you get errors (NOTAUTH? NOTIMP?) that indicate that the server the DNS
Update was sent to is not the primary (and the server isn't willing to
forward the update). Perhaps something needs to be said about this in
section 6 just to make sure that everyone understands that those errors
are not considered and the updater needs to take appropriate steps to
communicate with the proper server.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of David W. Hankins
> Sent: Friday, July 22, 2005 2:39 PM
> To: [email-masked]
> Subject: Re: [dhcwg] dhc WG last call 
> on<draft-ietf-dhc-ddns-resolution-09.txt>
> 
> On Fri, Jul 22, 2005 at 01:23:16PM -0400, Bernie Volz (volz) wrote:
> > There are two ways you can end up in section 6.3.4, either 
> from 6.3.1 or
> > 6.3.3.
> 
> Since it's a "may", I didn't pay particular attention to that clause
> in 6.3.1.
> 
> If you integrated something like the changes I discussed, I would
> append;
> 
> ...matter of local administrative policy.  Or, the updater may proceed
>    similarly to Section 6.3.4, except without the 
> prerequisites section.
> 
> Which is easier and more readable than double-talk within 6.3.4.
> 
> Personally I'd leave that whole bit as an excercise to the reader and
> just not say anything about going to 6.3.4 from 6.3.1.  This is not
> only a matter of "replacement policy" you're describing, it's a matter
> of playing fast and loose with the zone...where people mix 
> DHCP-managed
> and adminstrator mananaged namespaces (www.mydomain and 
> fredsbox.mydomain),
> this won't fly.
> 
> > If from 6.3.1, there is no DHCID RR associated with the name.
> 
> No, you only think there isn't a DHCID...only the master(s) know for
> certain.
> 
> 1) 6.3.1 is a regular DNS query.  It may be through a 
> recursive nameserver.
> 	That recursive nameserver may cache both positive 
> (existence) and
> 	negative (non-existence) results.
> 
> 2) You also might just as easily get an answer from an 
> authoritative server
> 	which has an older copy of the zone (that is, you or 
> your recursive
> 	server might have...).
> 
> 3) You might be in a race condition, where after your query 
> proving there
> 	is no DHCID, one was added.
> 
> So I think you should encourage the DHCID prerequisite, to at least
> make people think about why.
> 
> > Do you really think the complexity of saying this is worth 
> it? If the
> > server's policy is to overwrite entries, what does it matter what it
> > overwrites? (I can't see many servers ever doing this, 
> except perhaps in
> > an exception case where a server is the only server and has 
> losts its
> > stable storage.)
> 
> I do, but as I later mentioned, I don't think this is worth delaying
> the draft.  I think it's implicit the way the draft is 
> currently worded,
> the spirit of the DHCID record, and since we have so many 
> different name
> policies floating around people need to keep track of theirs. 
>  That in the
> general case, and not the 'may' conditional, 6.3.4 is entered 
> into as a
> matter of policy to replace an entry owned by another 
> dhcp-managed entity.
> 
> Ensuring that the name is dhcp-managed is just good practice, 
> if that's
> your policy.
> 
> Saying it out loud in the draft is just my preference.
> 
> > >     ... If the configured policy allows
> > >     replacement of existing records, the updater submits 
> a query which
> > >     contains:
> > > 
> > > 	o A prerequisite that a DHCID RR of any value exist for 
> > > this FQDN.
> > > 	o The deletion of all RRs for the FQDN.
> > > 	o The addition of the A and/or AAAA RR
> > > 	o The addition of the new DHCID RR.
> 
> -- 
> David W. Hankins		"If you don't do it right the 
> first time,
> Software Engineer			you'll just have to do 
> it again."
> Internet Systems Consortium, Inc.		-- Jack T. Hankins
> 

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

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 22 Jul 2005 12:54:09 -0700

> I'm inclined to leave the text as it is.

I'm fine with that.  Like I said, I think the language I suggested is
what the draft already implies to be most proper depending on what
naming policy you use.

> communicate with the proper server.

I'm concerned you might be suggesting that the 6.3.1 query should be
made against the master server, which I don't agree with.

Otherwise I obviously agree, there's no reason to describe 'base'
failures that are better addressed in dns protocol documents.

I think my complaint with section 6.3 is better characterized by the
overpopulation of orthogonal naming policies than what to do in timeouts
or other 'base' failures.

If I'd thought of it back then, I'd say all these naming policies belong
in their own, separate, drafts, each using the DHCID RR draft as a
compass.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg