Re: [nscp] Updating zone *content* in-scope or not?

[Paul Hoffman <[e-mail]>]

At 9:28 PM +0200 9/16/10, Lars-Johan Liman wrote:
>Hi, Paul!
>
>On Wed, Sep 15, 2010 at 02:57:35PM -0400, Jeffrey Hutzelman <[e-mail]> wrote
>>>> IMHO, zone content management certainly should be in scope.
>
>At 3:01 PM +0200 9/16/10, Stephane Bortzmeyer wrote:
>>> -1 for a practical reason: we already have several good ways to update
>>> zone content and two are standard and use the DNS (RFC 2136 and
>>> 5936).
>
>[e-mail]:
>> Aren't those only applicable when the zone admin is also running a DNS
>> server, brings it up to date, and then tells the DNS admin to
>> synchronize? And aren't there *many* other deployment scenarios for
>> DNS content?
>
>This discussion can continue from here to eternity and back - and
>probably will. ;-)

Given that it already has, and eternity is ahead of us, yes.

>I agree with Stéphane that there are already standardized mechanisms to
>handle zone content updates. I may well be that they require the zone
>admin to run a DNS server, but you _can_ (and that's an obvious future
>to me) send dynamic updates from an application that doesn't work as a
>DNS server _to_ the master server, so _some_ of your cases can probably
>be dealt with, but not all. *)

I was not aware of those applications. Can you point to some examples?

>I agree with you that there may be scenarios where these mechanisms are
>suboptimal or even inappropriate, but there is at list _a_ mechanism (or
>two) for that, whereas in the case of sending "commands" to the DNS
>server, there is none.
>
>So, my proposal is
>
>a) Let's cut out a limited piece of work for ourselves to start with,
>   and make sure we get to the other end of it in forseeable time.
>
>b) When we do so, we should focus on things for which we have _no_
>   current alternative, as opposed to things for which we have already
>   at least one alternative, imperfect as it may be.
>
>I.e., leave out updating zone content for now - at least zone content
>for which the receiving end is authoritative.

That works for me, although it should probably be written into the charter.

--Paul Hoffman, Director
--VPN Consortium